Imposition process and apparatus for variable imaging system

ABSTRACT

The present invention is useful for assembling a book. The inventive method includes the steps of specifying pagination information including an indication of whether a page is to be selectively included in the book, determining whether the page is to be assembled into the book based on the pagination information, and generating page description language instructions for production of the book in accordance with the pagination information.

RELATED APPLICATIONS

This application is a divisional of U.S. application Ser. No.08/802,337, filed Feb. 11, 1997, the disclosure of which is herebyincorporated by reference, and which, in turn, is a continuation-in-partof U.S. application Ser. No. 08/478,397, filed Jun. 7, 1995 and acontinuation-in-part of U.S. application Ser. No. 08/627,724, filed Apr.2, 1996, now U.S. Pat. No. 5,857,209.

TECHNICAL FIELD

The present invention relates generally to reproduction methods andsystems, and more particularly to a method of and system for selectivelyreproducing images.

BACKGROUND ART

Most printing systems in use today utilize printing plates or cylinderswhich are engraved or photochemically processed to create an imagethereon. Ink is then deposited on the plate or cylinder and the ink isthereafter transferred to a substrate, such as paper. In a conventionalprinting press, a number of pages are printed on a sheet of paper toform a signature which is then folded and assembled with othersignatures. The assembled signatures are then bound, trimmed andfinished by finishing apparatus to produce finished books, such asmagazines, catalogs or any other printed and bound matter.

Often, there is a need to produce different versions of books and/orcustomized books within a single press run. For example, it may bedesirable to produce a number of standard books together with a numberof books having additional and/or different signatures or pages therein.Also, it may be necessary or desirable to provide customized informationin the form of an address label, personalized information or the like onthe inside or outside of finished books. In either case, conventionalprinting systems are not easily adaptable to produce books of thesetypes.

A printing system which has the ability to produce differing bookversions and/or books with customized information is disclosed in RileyU.S. Pat. No. 4,121,818, assigned to the assignee of the instantapplication. The printing system includes a number of packer boxesdisposed adjacent a binding chain wherein each packer box stores aplurality of signatures. A control is included for controlling thepacker boxes to selectively feed signatures onto chain spaces of thebinding chain so that books of varying content can be produced.Customized information can be printed on the signatures by means of anink jet printer which is selectively operated by the control. Othertypes of customization can be effectuated, such as by inserting oronserting cards or the like.

Other systems for producing customized books are disclosed in Abrams etal. U.S. Pat. No. 3,899,165, Wong et al. U.S. Pat. Nos. 4,500,083 and4,674,052, Wong U.S. Pat. No. Re 32,690 and Berger et al. U.S. Pat. Nos.4,768,766 and 4,789,147.

Image manipulating systems have been developed which permit gathering ofimages in an office or home environment. For example, conventional wordprocessing programs, such as Microsoft® Word®, WordPerfect® and thelike, permit a user to import images into a page and also allow a userto command which pages of a document to print. In addition, macros(i.e., a sequence of commands) can be assembled and executed withinthese programs which can allow printing of particular document pages ina certain order. Still further, most word processing programs have mergecapability wherein a customized image is merged with other standardizedinformation and printed or displayed. As one example, customizedinformation in the form of addressee and address information may bemerged with standardized return address information and printed on aseries of envelopes.

A different image gathering capability provided by CAD (computer aideddesign) software, sometimes referred to as “layering,” involves thecreation and storage of a base page and one or more layer pages. A usercan issue commands to display or print the base page and one or more ofthe layer pages simultaneously atop one another to achieve an effectsimilar to the overlay of transparencies so that a composite pageappearance results.

While the foregoing image manipulating systems allow some imagegathering capability, none is effective to assist in the rapidproduction of different book versions. Of course, CAD systems areprimarily designed for line art and not text or graphic images, andhence are of only limited use. Further, if one were to use wordprocessing software to produce book versions it would be necessary toissue commands to separately print the pages of each book version justbefore such version is to be produced. That is, a user would have tocreate and store pages to be included in a first book version and thencommand the software to print as many copies of the first version as areneeded. Thereafter, the user would have to recall the pages of the firstversion from memory, edit and store the pages to create pages to beincluded in a second book version and then command the system to printthe required number of books of the second version. Similar steps wouldhave to be undertaken for each other book version to be produced.Alternatively, the pages of the different book versions could be createdand stored and thereafter printed together. In either event, where manybook versions are to be produced, such a process would be quitetime-consuming. In addition, image importation and merge routinesprovided as a part of word processing software are adapted for use on asub-page basis only and hence are of only limited usefulness in the bookproduction environment. Still further, data manipulated by wordprocessing software are largely (if not entirely) in symbolic format. Asa result, data to be displayed or printed must be first rasterized by araster image processor (RIP), which utilizes complex and time-consumingcomputational routines which further increase production time to aneconomically impractical level.

Recently, new printing systems have been developed, called “demandprinters,” which are capable of high speed printing of images fromelectronic representations thereof. The demand printer produces highquality color (or black and white) images using a set of fusible tonersin an electrophotographic process. More particularly, a web of paper ispassed adjacent a series of drums, each of which has beenelectrostatically charged according to an image pattern for a particularcolor to be applied to the web. The charge is transferred to the paperand an oppositely charged toner of the proper color is brought intocontact with the paper. The oppositely charged web and toner attract sothat the toner is held on the paper as other colors are applied thereto.The toners and paper are thereafter heated to fuse the toners to thepaper to produce the final image. The web is then cut into sheets (or“forms”) and the forms are further processed as needed to produce afinal product.

Unlike conventional presses which utilize engraved or photochemicallyprepared plates or cylinders, demand printers are capable of rapidlyprinting high quality images of differing content owing to the fact thatthe images are produced by an electrophotographic process. That is,instead of the need to replate and re-engrave a gravure cylinder when adifferent image is to be printed therewith, it is only necessary tochange the charge applied to the drums of the printer in order to makesuch change. Thus, different images can be printed by the same printerwithout significant delays. This advantage makes the demand printerdesirable for use in certain production environments.

Warmus et al. U.S. patent application Ser. No. 08/478,397, entitled“Variable Imaging Using An Electronic Press” discloses an apparatus andmethod for controlling an electronic press so that fixed and variableinformation may be printed in a simple and effective manner. Moreparticularly, first and second sets of template data representingassociated first and second template pages, respectively, are developed.Each set of template data includes master data representing fixedinformation and area data representing an area of a page for variableinformation. A database is also developed having a number of entrieseach of which represents variable information. The printer is operatedin accordance with the sets of template data and the entries in thedatabase such that the first and second template pages are displayedwith selected variable information.

The Warmus et al. apparatus and method generates a page definitionlanguage representation of each single page and thereafter generates apage definition language representation of each imposed flat, i.e., eachside of a piece of paper to be printed with two or more pages. Such aprocedure can be computationally expensive and may limit productivity.

SUMMARY OF THE INVENTION

According to one aspect of the present invention, a method of assemblinga book includes the steps of specifying pagination information includingan indication of whether a page is to be selectively included in thebook, determining whether the page is to be assembled into the bookbased on the pagination information, and generating page descriptionlanguage instructions for production of the book in accordance with thepagination information.

Preferably, the determining step includes the step of analyzing variableinformation areas of the page. The inventive method may further includethe step of analyzing press commands directed to production of the bookto determine whether the page is to be assembled into the book. Theinventive method may still further include the step of generating apagination file having data representative of the paginationinformation.

Preferably, the pagination information includes an indication of amaximum number of pages for the book. The pagination information mayinclude filler page information. The pagination information alsopreferably includes a specification of whether the page should be forcedto one of a right side and a left side of the book.

In one embodiment, the inventive method further includes the step ofspecifying page description language instructions to produce a barcodeon the page. The barcode may be indicative of tracking information.

In another embodiment, the step of generating page description languageinstructions includes the step of generating instructions for productionof page numbering information on the page. The step of generating pagedescription language instructions may also include the step ofgenerating instructions for insertion of filler pages in accordance withthe pagination information.

Preferably, the inventive method further includes the step of deliveringthe page description language instructions to an electronic press toprint the book.

In yet another embodiment, the step of specifying the paginationinformation includes the step of providing a user interface for entry ofthe pagination information.

Other features and advantages are inherent in the apparatus claimed anddisclosed or will become apparent to those skilled in the art from thefollowing detailed description in conjunction with the accompanyingdrawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating a prior art method of producingbooks;

FIG. 2 is a block diagram of a method of producing books implementingthe present invention;

FIG. 3 is a block diagram illustrating an exemplary system forimplementing the method of the present invention illustrated in FIG. 2;

FIG. 4 is a block diagram illustrating one of the demand printingsystems of FIG. 3 in greater detail;

FIG. 5 is a generalized diagram of the steps implemented by the methodof the present invention;

FIGS. 6 a and 6 b are elevational views of portions of a sample bookthat may be produced by the present invention;

FIGS. 7 a, 7 b and 8 a, 8 b are elevational views of portions of othersample books that may be produced by the present invention;

FIG. 9 is a flowchart illustrating programming that may be executed by auser on a personal computer to create the template files 105 of FIG. 5;

FIGS. 10 a-10 f, when joined along similarly-lettered lines, togetherrepresent programming executed by the control unit 52 of FIG. 3;

FIG. 11 is a flowchart illustrating the programming implemented by thecontrol unit 52 to generate a page description language instruction setspecifying which pages should be printed and how the pages should bepositioned (or imposed) for printing;

FIG. 12 is a sample window to prompt a user for the information neededto create a pagination file;

FIG. 13 is a flowchart illustrating in detail the programmingimplemented by the block 348 of FIG. 11 which determines which pagesshould be printed for a particular record in the press command file;

FIG. 14 is a flowchart illustrating in detail the programmingimplemented by the block 350 of FIG. 11 to determine whether the pagesshould be forced to the left or right-hand side of the book;

FIG. 15 is a flowchart illustrating in detail the programmingimplemented by the block 352 of FIG. 11 to pad the pages included in thebook into a multiple of the number of pages to be printed on a sheet;

FIG. 16 is a sample window to prompt a user to provide variousinformation to select imposition and printing styles;

FIG. 17 is a flowchart illustrating the programming implemented to RIPpage files to Tiff format for use in “Get Tiff” imposition in accordancewith the present invention;

FIG. 18 is flowchart illustrating the programming implemented to imposepages using “Get Tiff” imposition in accordance with the presentinvention;

FIG. 19 is a more detailed block diagram of the print system 79 (shownin FIG. 4) incorporating the imposition-on-the-fly procedures of thepresent invention;

FIG. 20 is a flowchart illustrating the standard operation of the Level2 PostScript® showpage operator;

FIG. 21 is a flowchart illustrating the program steps implemented by theredefined Postscript® initclip operator according to theimposition-on-the-fly procedures of the present invention;

FIG. 22 is a flowchart illustrating the program steps implemented by theredefined Postscript® transform operators according to theimposition-on-the-fly procedures of the present invention;

FIG. 23 is a flowchart illustrating the program steps implemented by theEnableVirtualDevice procedure according to the imposition-on-the-flyprocedures of the present invention;

FIG. 24 is a flowchart illustrating the program steps implemented by theDisablePageDevice procedure according to the imposition-on-the-flyprocedures of the present invention;

FIG. 25 is a flowchart illustrating the program steps implemented by theSetPortrait procedure according to the imposition-on-the-fly proceduresof the present invention;

FIG. 26A is a diagram illustrating the conversion of a portrait-orientedpage to a landscape-oriented page according to the SetPortrait procedureof FIG. 24;

FIG. 26B is a diagram illustrating the conversion of alandscape-oriented page to a portrait-oriented page according to theSetPortrait procedure of FIG. 24;

FIG. 27 is a flowchart illustrating the program steps implemented by thesetvirtualdevice procedure according to the imposition-on-the-flyprocedures of the present invention;

FIG. 28 is a flowchart illustrating the program steps implemented by theImposeJob procedure according to the imposition-on-the-fly procedures ofthe present invention;

FIG. 29 is a flowchart illustrating the program steps implemented by theImposeFile procedure according to the imposition-on-the-fly proceduresof the present invention;

FIG. 30 is a flowchart illustrating the program steps implemented by theMakeNull procedure according to the imposition-on-the-fly procedures ofthe present invention;

FIG. 31 is a flowchart illustrating the program steps implemented by theredefined EndPage procedure according to the imposition-on-the-flyprocedures of the present invention;

FIG. 32 is a flowchart illustrating the program steps implemented by theredefined BeginPage procedure according to the imposition-on-the-flyprocedures of the present invention;

FIG. 33 is a flowchart illustrating the program steps implemented by theVsave procedure according to the imposition-on-the-fly procedures of thepresent invention;

FIG. 34 is a flowchart illustrating the program steps implemented by theVrestore procedure according to the imposition-on-the-fly procedures ofthe present invention;

FIG. 35 is a flowchart illustrating the program steps implemented by theredefined Postscript® save operators according to theimposition-on-the-fly procedures of the present invention;

FIG. 36 is a flowchart illustrating the program steps implemented by theredefined PostScript® restore operator according to theimposition-on-the-fly procedures of the present invention; and

FIG. 37 is a flowchart illustrating the program steps implemented by theredefined PostScript® grestore and grestoreall operators according tothe imposition-on-the-fly procedures of the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1 illustrates a prior art method of producing books, for example,as shown in the above-identified Riley et al. '818 patent. During apublishing step 20, the contents of one or more book versions aredetermined. Each version may comprise, for example, a set of standard orcommon pages. In addition, some of the versions may include one or moreadditional pages or other customized information. Thereafter, during apreliminary step 22, color correction of color images is undertakentogether with undercolor removal and screening for halftone images.During a prepress step 24, page imposition is effected and printingcylinders or plates are prepared. The plates or cylinders are then usedduring a printing step 26 to prepare signatures which are loaded intopacker boxes (not shown). As noted in the Riley et al. '818 patentidentified above, the signatures are then selectively collected on agathering chain (not shown) during a book assembly step 28 and thegathered signatures are bound and trimmed to create the books. The booksare thereafter distributed during a step 30 to users via one or moredistribution systems, for example, the U.S. Postal Service.

As should be evident from the foregoing, customization occurs during thebook assembly step 28, inasmuch as the choice of particular signaturesto be included in a book is made at that time. In addition, customizedinformation can be printed onto selected signatures using an ink jetprinter disposed adjacent the gathering chain. Thus, for example,addressee information can be printed by the ink jet printer on assembledbooks so that preprinted addressee labels need not be used. Other typesof customization can be effected at this time, for example, by insertingor onserting cards into or onto a stack of collected signatures,affixing a specialized or customized cover on a gathered stack ofsignatures, or the like. Customization at this point in the productionprocess is simpler and less expensive than, for example, separatelyprinting each book version with customized information.

FIG. 2 illustrates a block diagram of a method 40 according to thepresent invention which may be used in place of the method of FIG. 1 toproduce books. The method 40 includes a step 42 which utilizes theoutput of publishing and preliminary steps 36, 38 and produces books fordistribution according to the step 30 of FIG. 1. The step 42 creates oneor more master and variable page files in, for example, a pagedescription language (PDL) such as PostScript® (PostScript® is atrademark of Adobe Systems, Inc. for its page description language)representing pages to be produced. In addition, as noted in greaterdetail hereinafter, a press command file (also referred to as a “bookticket” file) is developed which specifies the manner in which datacontained within the master and variable page files are to be merged toproduce printed pages. The format of the press command file may be, forexample, of the form specified by Barco Graphics of Gent, Belgium, whichis particularly suited for control of a DCP-1 digital color pressmanufactured by Xeikon of Mortsel, Belgium. Alternatively, the format ofthe press command file may be of the form specified for control of aDocuPrint printer, manufactured by Xerox Corporation. Other demandprinters include the IBM 3900 or Siemens 2090 Twin or 2140 Twin. Itshould be noted that the apparatus and method of the present inventionare not limited to use with a particular type of demand printer or aparticular system for controlling such a printer, inasmuch as theinvention can be adapted for use with any type of printer or controlwhether located locally or remotely.

The master and variable page files and the press command file areconverted by a collator and raster image processor (RIP) into bitmapswhich may be stored in a memory. The stored bitmaps are used to controlone or more demand printers and/or any other type of display device,such as a laser printer, a CRT, an LCD display or the like so that thedevice displays pages having fixed and variable information thereon.Alternatively, the master and variable page files may be premerged tocreate a plurality of combined files each representing a page to bereproduced with master and variable information. The combined files canbe then sent to any type of printer or other display device, whetherlocal or remote. Also, the combined files can be converted to a suitableformat (e.g., Acrobat® PDF format) and transmitted to a remote locationusing a facsimile machine, e-mail, the internet/worldwide web or othertransmission medium, if desired. Advantageously, the combined files maybe transmitted over the Internet or any other networked or linkedcomputers, such as a company intranet. In this case, as electronic pagecontaining customized data can be sent over the Internet/intranet to auser-based upon user demographic(s), a user search and/or any otheridentifiable user interest(s). For example, a customized internet pagecould be sent with links to other web pages of interest to a user or acustomized page may be sent in response to a user search for informationon a particular subject. Alternatively, or in addition, ads could begenerated and sent as a web page to one or more users based upon userdemographics. As a further example, personnel information concerning aparticular employee may be sent to the employee in response to a requestfor information.

If the pages are to be displayed by rendering the pages on the demandprinter, the assembled books may be bound and trimmed and, if desired,further customized, during a finishing step.

FIG. 3 illustrates a system 50 which implements the steps 36, 38 and 42in the method 40 of FIG. 2. A control unit 52, which may be implementedby a personal computer or another type of computer, includes a memory 53and stores therein data representing images to be printed. As noted ingreater detail hereinafter, the data may be specified by a publisherusing a personal computer 54 or any other type of computer and maycomprise one or more template files specifying pages to be produced withmaster or fixed-printed information (i.e., printed information whichdoes not vary from book to book of the same version) and variableprinted information (which typically varies from book to book). Thevariable information may be stored in a database created by thepublisher and the template file(s) specify the locations on particularpages for variable information stored in the database, as noted ingreater detail hereinafter.

If desired, image data may be obtained from any other type of device ordevices, such as a scanner which scans input copy, data supplied over anetwork or any other source. The control unit 52 is further responsiveto control and makeready files and causes one or more demand printingsystems 62 to print desired pages. While three demand printing systems62 a-62 c are illustrated in FIG. 3, it should be understood that thecontrol unit 52 may operate a different number of demand printingsystems, as desired. Also, the control unit 52 may operate a fax machine64 and/or may communicate with other remote devices to send properlyconverted combined files, as desired and as noted above. In the case ofother remote devices, a modem 65 may be operated by the control unit 52to transmit data representing one or more pages to be displaced by adisplay device at a remote location over phone lines (land lines and/orcellular) or a combination of phone lines and the Internet.Alternatively or in addition, the data may be sent to a local or remotelocation at least in part over an intranet or another computer networkthrough a direct connection therewith. The combined files may be printedor may alternatively be reproducible in a different medium and/or maycomprise a non-static image or other information, e.g., movies or audio.

The pages printed by the demand printing system 62 may be supplied to afinishing apparatus 66 which includes various auxiliary productiondevices and device interfaces for assembling the pages to producefinished books which are ready for distribution. The finishing apparatus66 may include one or more gathering devices 70 for gathering printedpages into books, one or more ink jet printers 72 for printingadditional customized information, such as addressee information, oneach book, one or more label printers 74 for printing address labelsand/or other control devices 76. In addition, one or more detectors 78may be provided to sense when a defective book is produced. The controlunit 52 may be responsive to the output of the detector 78 to reorder adefective book at an appropriate point in the production sequencethereof so that advantage can be taken of postal discounts, if possible.

One or more components of the finishing apparatus 66 may be physicallylocated on the demand printer (i.e. “online finishing”). Alternatively,the finishing apparatus 66 may be physically separate from the demandprinter (i.e. “offline finishing”).

FIG. 4 illustrates the demand print system 62 a of FIG. 3 in greaterdetail, it being understood that the systems 62 b and 62 c arefunctionally similar. The system 62 a includes a print system 79 havinga press controller 80, a collator 81 and a raster image processor (RIP)82 which are operable in response to press commands generated by thecontrol unit 52. A collator is an electronic device for storing rasterimage processor files (i.e., bitmap files) and delivering selected filesto a digital press in real time, such that the digital press can run atfull speed while processing and printing unique page data for each bookproduced on the press. The RIP 82 converts the page files to bitmapformat or any other format, such as a symbolic printer control language.The collator 81 includes memory in the form of mass storage drives andphysical memory and collates the bitmap page files. If desired, thecollator 81 and/or RIP 82 may comprise a part of the press controller80. The controller 80 instructs the collator 81 to send page files to ademand printer 84. The print system 79 may comprise the PrintStreamersystem, manufactured and marketed by Barco Graphics of Belgium, whilethe demand printer 84 may comprise the Xeikon DCP-1 digital color pressnoted above. Alternatively, the demand printer 84 may be a DocuPrintprinter manufactured by Xerox Corporation and the RIP 82 may be a XeroxDocuPrint RIP. It should be noted that a different print system and/ordemand printer may alternatively be used, such as the Indigo printermanufactured by Indigo NV, of Maastricht, Netherlands, if desired.

FIG. 5 illustrates in diagrammatic generalized form the method of thepresent invention. For the purpose of explaining the present invention,as an example, it will be assumed that the demand print system 62 a willbe operated to produce a number of multiple-page books in the form of abrochure in duplex (or “saddle-stich”) format. FIGS. 6 a and 6 billustrate four pages P1-P4 printed on a single sheet of paper 100 andto be included in a brochure. The sheet of paper 100 includes a firstside 100 a with printed pages P1, P4 thereon and a second side 100 bwith pages P2, P3 printed thereon. (As will become evident hereinafter,the use of designations P1-P4 is not meant to imply that such pages willnecessarily become pages 1, 2, 3 and 4 of the finished book.) Inaddition, pages P1-P4 are imposed such that the page P1 is placed on aright-hand portion 100 a-r of the side 100 a while the page P4 is placedon a left-hand portion 100 a-l of the side 100 a. Further, the page P2is placed on a left-hand portion 100 b-l of the side 100 b while thepage P3 is placed on a right-hand portion 100 b-r of the side 100 b. Inthis fashion, when the sheet of paper 100 is folded along a fold line102 with the pages P1 and P4 on the outside, the pages P1-P4 appear insequence. (The format shown in FIGS. 6A and 6B is often referred to as“saddle stitch” imposition and is commonly used in magazines.) Becauseeach book to be produced in this example includes multiple sheets ofpaper (or “forms”), each folded once along a fold line, the impositionprocess takes into account shingling effects but not bottling effects.It should be noted both of that such effects will generally have to betaken into account when more than two pages are to be printed on asingle side of a sheet of paper and thereafter folded multiple times andassembled with other multiple-folded printed sheets of paper to create abook.

In addition to the foregoing, in the first example, assume that thepages P1 and P4 will become the outside front and back covers,respectively, of a finished book and include variable and fixedinformation thereon. Further, assume that the pages P2 and P3 willbecome the inside front and back covers, respectively, (as must be thecase if P1 and P4 are the outside front covers) and include fixedinformation only thereon. For example, the page P1 may include variableinformation in the form of a personalized message, a variable image, orthe like in an area 110 whereas the page P4 may include other variableinformation in an area 112, for example, postal information for mailingthe brochure to an addressee. Corresponding front and back pages of theremaining books may include different variable information. Theremaining printed information on pages P1-P4 may be identical to theprinted information on corresponding pages of remaining books.

The books to be produced may include the same or differing number offorms and may have the same or differing numbers of pages. For example,the pages P1-P4 may be assembled with a first number of other formsprinted with twelve additional pages to produce a first book havingsixteen pages. Another book to be produced in the same run may includesome or all of pages P1-P4 and a second number of forms printed withtwenty other pages, some of which may or may not be identical to thetwelve additional pages of the first book. Filler pages may be placed insome or all books to cause such book(s) to have a certain number ofpages. This may be necessary or desirable to result in a book lengthwhich is evenly divisible by four (in the event pages are imposed astwo-page spreads) and/or to insure that particular page(s) appear on theleft-hand or right-hand side in the finished book.

In fact, the books to be produced in the same press run may be differentin terms of page content and/or appearance, book length, book size (bychanging page imposition parameters), book version, etc . . . .Specifically, for example, the pages of FIGS. 7 a, 7 b and 8 a, 8 b maybe produced and assembled in different book versions together with thebook version incorporating the pages of FIGS. 6 a and 6 b in the sameproduction run or job. Pages P5-P8 of FIGS. 7 a and 7 b are identical tothe pages P1-P4, respectively, of FIGS. 6 a and 6 b except that anadditional area 113 is provided on the page P5 for placement of variableinformation, in addition to the areas 110 and 112. Because of theaddition of the area 113, the remaining master information appearing inan area 114 differs from master information appearing in an area 116 ofthe page P1 of FIG. 6 a.

The book version incorporating eight pages P9-P16 of FIGS. 8 a and 8 bdiffers from the book versions incorporating the pages of FIGS. 6 a, 6 band 7 a, 7 b not only in terms of content of master and variableinformation, but also number of pages and page size. Specifically, thepages P9, P12, P13 and P16 are to be printed on a first side 117 a of asheet of paper 118 and the remaining pages P10, P11, P14 and P15 are tobe printed on a second side 117 b of the sheet 118. In addition, thepages P11-P14 are printed upside down relative to the remaining pages sothat, when the sheet 118 is folded first along a fold line 119 a andthen along a fold line 119 b, the resulting pages P9-P16 appear inorder. Thereafter, the folded sheet 118 is trimmed to separate the pagesP9-P16. As should be evident, the pages P9-P16 are one-half the size ofthe pages P1-P8, and further include different master and variableinformation thereon. The demand printer may also have multiple papertrays to select different paper sizes, stocks, colors, etc. orpreprinted sheets to be included in the finished book.

Referring again to FIG. 5, one or more template files 106 are developedby a publisher specifying the content (including appearance) of fixedinformation and the positioning of all information (i.e., fixed andvariable) on the different books or book versions. A database 108 isalso developed by the publisher using the personal computer 54specifying the content of variable information to be placed in variableinformation areas, for example, the areas 110, 112 on the pages P1, P4,respectively, of FIGS. 6 a and 6 b. The database 108 further includescontrol information, as noted in greater detail hereinafter.

The template files 106 include data specifying the position and contentof fixed information on the pages to be printed. Specifically, thetemplate files 106 define template pages wherein each template pageincludes data representing any fixed information to be reproduced oncorresponding pages of the books or book versions and area datarepresenting any area(s) on the corresponding pages where variableinformation is to be reproduced. The template files are duplicated tocreate working files. One set of working files is stripped of all areadata relating to placement of variable information to create strippedmaster page files 120 defining template pages having only fixedinformation thereon. The stripped master page files are then convertedinto PDL master page files 122 expressed in a page description language,such as PostScript®.

Optionally, the PDL master page files 122 may be converted intotwo-pages spreads by a page make-up program such as QuarkXPress®.Preferably, however, the PDL master page files 122 are provided to theprint system 79 and imposed according to the imposition processes of thepresent invention, as explained in detail below.

A further set of working files is stripped of all fixed information tocreate stripped variable page files 126 defining template pages havingfixed information removed therefrom and further having the area datadefining the areas 110, 112. The data representing template pages havingvariable information thereon are expanded into a set of intermediatepage files. In the example of FIGS. 6 a and 6 b and under the assumptionthat three books are to be printed, two intermediate page files 130, 132are thus produced. The file 130 includes a file portion P1-a definingthe position of variable information to be produced on the page P1 forthe first book. Two other file portions P1-b and P1-c define theposition of variable information to be produced on the front outsidecovers of the remaining two books. In like fashion, file portions P4-a,P4-b and P4-c represent the position of variable information to bereproduced on the back outside covers of the three books. At this point,data is also contained in each of the files 130, 132 identifying theentries in the database 108 to be placed in the areas 110, 112 duringprinting.

The files 130, 132 are then converted into variable page files 134, 136.The files 134, 136 are identical to the files 130, 132, respectively,except that the data in each file identifying entries in the databaseare replaced by the actual data stored at such entries. The files 134,136 are then converted into files 137, 138 in a PDL format, for example,PostScript®.

Like the master PDL files 122, the variable PDL files 137, 138 may beconverted into two-page spreads by a page make-up program such asQuarkXPress®. Preferably, however, the variable PDL files 137, 138 areprovided to the print system 79 and imposed according to the impositionprocedures of the present invention, as explained in detail below.

The print system 79 operates in response to the press commands in apress command file 140 and merges the PDL master page files 122 with thePDL variable files 137, 138 to create the finished books or bookversions. Alternatively, the master page files 122 may be premerged withthe PDL variable files 137, 138 before the files are provided to theprint system 79.

FIG. 9 illustrates a flow chart of programming executed by the personalcomputer 54 for creating the template file(s) 106 of FIG. 5. Theprogramming may be written as an extension of QuarkXPress®, a pagemake-up program distributed by Quark, Inc. of Denver, Colo. TheQuarkXPress® program may be adapted for operation on the Apple®Macintosh® operating system or any other operating system, such as theMicrosoft Windows® operating system. Alternatively, a different pagemake-up program may be used, if desired.

During the make-up process for a document consisting of one or morepages, a template file is created for each book version to be produced,or, where a book is to include two or more parts (referred to as“sections” hereinafter) a template file may be created for each section.At a block 150 a user may select an area of a page for reproduction ofvariable information therein, at which point a line object, a textobject or an image object may be selected. A block 152 then checks todetermine which type of object has been selected. If a text object hasbeen selected, indicating that variable text is to be inserted at apoint defined by the current cursor position on the computer display,the name of the appropriate field in the database 108 is inserted intothe template file at the insertion point defined by the current cursorposition by a block 154. If the user wishes to designate more areas forvariable information (block 156) control returns to the block 150 toawait selection by the user. If the user then selects an image object, abox is defined by the user to contain an image at a desired location ona selected page. Control from the block 152 thereafter passes to a block158 which inserts a dummy picture file and an indication of the properdatabase field name in the template file for the page at the locationindicated by the current cursor position. The user will thereafter seethe dummy picture file at the insertion point on the display of thecomputer 54 when the page is viewed. The dummy picture file will displayan indication of which database field will be used for insertion on therespective pages.

Following the block 158, a block 160 prompts the user to enter anindication of whether the image object is to be displayed in one ofseveral display formats. If the image is to be displayed in other thanthe original size thereof, a block 162 sets a subname defined for theimage to “fit,” indicating that the image is to be scaled to fit thebox. If the image is to be displayed in the original size thereof, ablock 163 prompts a user to select a position for the image at aparticular location in the box defined therefor, such as the upperleft-hand corner, the lower right-hand corner, or the like. If the userdoes not select a position, the image is placed in the upper left cornerof the image box. Control thereafter proceeds to the block 156.

If the block 152 determines that a line object has been selected,control returns directly to the block 150, inasmuch as variableinformation cannot be entered into a line object. The resulting pagetemplate files(s) are stored on a storage medium, such as an opticaldisc or other storage device, and/or the files(s) are downloadedtogether with the database to the control unit 52.

At any point during the page make-up process, other functional aspectsof the QuarkXPress® program may be invoked to both master and variableaspects as necessary to produce finished pages.

The database 108 is assembled by creating an ASCII file having aplurality of records wherein each record includes one or more fieldsentered into the database in tab-delimited format (i~e, the fields areseparated from one another in each record by tab keystrokes and therecords are separated from one another by line returns) and wherein thefields are arranged under field names of a header. Each field mayinclude text to be reproduced on a page or a name of an image filestored in the memory 53 and defining an image to be reproduced on apage.

In addition to the foregoing data, the database 108 may include anoptional field designating the number of copies of each book to beproduced, an optional townsort image field, a version identificationfield indicating book version number if multiple book versions are to beproduced, an optional distribution list field, control data and thelike.

A sample database is set out below having a header consisting of twelvefields (i.e., “version,” “addressline1,” “addressline2,” etc.) and anumber of records, nine of which are shown, each having twelve fields:Version Addressline1 Addressline2 Addressline3 Addressline4 Addressline5Price1 Image1 Price2 Copies Barcode Townsort 01 William 123 Elm ChicagoIllinois 606248923 $22.95 Shoes $21.95 1 !606248923! Doe 03 Hugh 56Maple Chicago Illinois 606248923 $21.95 Shirt $20.95 1 !606248923!Jorgensen 02 Jay P. Morgan 1313 Park Chicago Illinois 606248924 $24.95Pants $22.95 1 !606248924! ▪ 02 Joe Louis 819 Elm LaGrange Illinois605251093 $19.95 Pants $18.95 1 !605251093! 03 John 926 LaGrangeIllinois 605251093 $19.95 Shoes $15.25 1 !605251093! Smith Cossit 01 Len882 LaGrange Illinois 605251093 $19.95 Shoes $17.25 1 !605251093!Johnson Monroe 02 Janet 916 LaGrange Illinois 605251094 $24.95 Pants$21.95 1 !605251094! ▪ Cizmar Monroe 03 Jay 88 W. Brookfield Illinois605241391 $21.95 Shirt $19.95 1 !605241391! Schroeder 77th 03 Danielle129 Brookfield Illinois 605241391 $22.95 Shirt $19.95 1 !605241391! ▪Johnston Madison

In the example of FIGS. 6 a and 6 b, the field names ADDRESSLINE1through ADDRESSLINE5, BARCODE and TOWNSORT may appear in the area 112and one or more of the field names PRICE1, IMAGE1 AND PRICE2 may appearin the area 110. The COPIES field may be used as a control code toselect the number of book copies to be produced.

Once the template file(s) 106 and the database 108 are assembled, theprogramming of FIGS. 10 a-10 f may be executed by the control unit 52 tocreate the master page file 122, the final variable page files 137 and138, and the press command file 140. Referring first to FIG. 10 a, ablock 170 prompts a user to select a template file 106 and a block 172opens the database 108. A block 174 then reads and stores in a list thedatabase field names for later reference and a block 176 prompts a userto enter information indicating a section number and whether pages areto be printed in simplex (i.e., single-sided) or duplex (i.e.,double-sided) format. The section number identifies the order in whichmultiple sections are to be processed for a particular book. The usermay also be prompted to enter a selective processing code identifying aparticular book version to process if multiple versions are to beproduced during a single press run.

Following the block 176, a block 177 begins the process of strippingvariable information from the template file opened by the block 170 toobtain the stripped master file 120 of FIG. 5. The block 177 selects afirst page for processing and a block 178 checks to determine whetherthere are any images in the template file and, if images are located, ablock 180 selects a first image.

A block 182 identifies the file name for the image and a block 184checks the field list to determine whether the file name is includedtherein. If the file name for the image is included in the field list,then the image comprises variable information and a block 186 deletesthe image block. A block 187 then identifies and saves the image boxlocation on the page, the characteristics of the image box, such as thesize, skew, background color and subname and the like and further savesthe field name of the image from the database 108. Also, a counter inthe memory 53 which tracks the number of variable image boxes on thepage is incremented.

Otherwise, if the block 184 determines that the file name is not in thefield list, then the image contains only master information. A block 188then also saves the image box location on the page and thecharacteristics of the image box. Also, a counter in the memory 53 whichtracks the number of master image boxes on the page is incremented.

A block 189 then checks to determine whether all images have beenprocessed. If not, a block 190 selects a next image and control returnsto the blocks 182-189. Control remains with such blocks until the block189 determines that all images have been processed and control thenpasses to a block 192. Control also passes to the block 192 from theblock 178 should the latter determine that there are no images in thetemplate file.

The block 192 determines whether any text boxes are present in the opentemplate file. If at least one text box is present, a block 194 selectsand parses a first text box and a block 196 (FIG. 10 b) checks todetermine whether the text box includes at least one of the field namesof the database 108. If so, then it has been determined that the textbox includes variable information and a block 198 deletes the text box.A block 199 then stores the text box location, the insertion points inthe text box at which variable information is to be printed and thecharacteristics of the text box and the field names of the database 108identified in such text box in the memory 53. In addition, a variabletext box counter is incremented representing the number of variable textboxes appearing on each page.

Otherwise, if the block 196 determines that the text box does notinclude any field names from the database, then the text box containsonly master information. A block 200 stores the text box location in thememory 53. In addition, a master text box counter is incrementedrepresenting the number of master text boxes appearing on each page.

Control then passes to a block 202, which checks to determine whetherall text boxes in the template file have been processed. If not, a block204 selects and parses the next text box in the template file andcontrol returns to the blocks 196-202. Control remains with such blocksuntil all text boxes have been processed, whereupon a block 206determines whether all pages have been processed. If not, a block 208selects a next page and control returns to the block 178 (FIG. 10 a).Otherwise, a block 210 saves the resulting file as the stripped masterfile.

Alternatively, if a page contains a lot of formatting information (i.e.tabs, fonts, etc.), a rich text file (which includes such formattinginformation) may be created offline from the database. The text box maythen open the rich text file and read the information from the file. Theuse of the rich text file speeds up the processing time.

Also, once a placeholder on a page has been “filled in” with informationfrom the database field, the program may mark the corresponding text orimage box as “touched.” Thus, if the text or image box is “untouched,”the program can skip processing of that text or image box, also speedingup the total processing time.

Control also bypasses the blocks 194-202 and proceeds directly from theblock 192 to the block 206 if the block 192 determines that there are notext boxes in the open template file.

Following the block 210, a block 212 converts the stripped master fileinto the PDL master page file 122 of FIG. 5. At the same time, aninitialization (or INI) file may be created. The format and existence ofthe INI file depends on the type of demand printer utilized. Forexample, the DocuPrint demand printer does not require the use of an INIfile. However, the Barco RIP requires the use of an INI file.

The INI file (in ASCII code) for the Barco RIP is created according tothe following format: name: [file path\name] psx: [dimension] psy:[dimension] ssx: [dimension] ssy: [dimension] posx: [dimension] posy:[dimension] duplex: [zero or one] orientation: [zero or one] output:[filename] copies: [number]

Where “psx” and “psy” refer to finished page sizes in x and ydirections, “ssx” and “ssy” refer to cut sheet size in x and ydirections, “posx” and “posy” refer to offsets in x and y directionsspecifying placement of each page on a cut sheet, “duplex” refers tosingle or two-sided printing, “orientation” refers to portrait orlandscape printing, “output” refers to the name of the output file and“copies” refers to the number of copies to be printed. A sample INI filewhich specifies parameters for printing of a file called MYJOB.PS is asfollows: Name: C:\jobs\myjob.ps psx: 8000 psy: 11000 ssx: 11500 ssy:9000 posx: 150 posy: 150 duplex: 1 orientation: 1 output: myjob.pscopies: 1In the foregoing example, one copy of the file MYJOB.PS is to be printedin duplex and portrait formats at an offset of 0.15×0.15 inches from acorner of a finished sheet of paper 8×11 inches cut from a sheetoriginally having dimensions of 9×11.5 inches.

For the DocuPrint (or any other demand printer which does not use an INIfile), a queue is created which contains the same parameters (andpotentially additional parameters which may invoke the functionality ofan inline finisher, or other apparatus) as the INI file.

Following the block 212, a block 214 then reopens the same template fileoriginally opened by the block 170 and deletes all the master image andtext boxes. A block 216 than saves the resulting file as the strippedvariable file 126 of FIG. 5.

A block 218 then creates a temporary file containing a table of thecurrent page number and a number representing the name of the databasefield placed by the block 154 at the insertion point. The file iscalled, for example, *.VARS (where * is a user-selected file name). The*.VARS file thus contains pairs of page numbers and database columnnumbers that indicate where in the database variable information for thepage comes from. For example, the *.VARS file may contain the followinginformation: 1 7 8 43 9 44 10 45 11 46 11 47 13 50 14 52 15 50 15 51In the example above, page 1 contains variable data from column 7 of thedatabase, page 8 contains variable data from column 43 and page 11contains variable data from column 46 and 47. Further, the *.VARS filemay contain separate pairings for images and text.

Control then passes to block 242 (FIG. 10 c) which creates a workingcopy of the stripped variable file 126. A first page having variabledata thereon is selected and data representing the remaining pages inthe file are deleted by a block 244. In the example of FIGS. 6 a and 6b, the block 244 creates a file defining the front cover of a book withall fixed information deleted therefrom and an area reserved forvariable information.

Following the block 244, a block 246 selects a first record in thedatabase 108 and a block 248 reads the record. An optional block 250checks to determine whether a selective processing code has been enteredby the user indicating that the page is to undergo selective pageprocessing. As noted above, the apparatus and method of the presentinvention may be utilized to produce not only books of a single version(i.e., where corresponding pages differ only in terms of the variableinformation stored in the database) but also books of differentversions. In the latter case, the books of different versions havedifferent fixed and variable information. The fixed and/or variableinformation may vary in terms of content or appearance (i.e., style,location, rotation, position, etc.) or both in different versions.

If the block 250 determines that selective page processing is to beundertaken, then a block 252 checks to determine whether the databaserecord read by the block 248 is to be utilized on the page currentlyunder consideration. The block 252 accomplishes this by checking theversion identification field in the database to determine if thatversion is being used. If this is not the case, a block 253 checks todetermine whether the record currently under consideration is the lastin the database. If so, control passes to a block 294 of FIG. 10e.Otherwise, a block 254 selects a next record. in the database 108 andcontrol returns to the block 248 where the next database record is read.

If the block 250 determines that selective page processing is not to beundertaken, or if the block 252 determines that the record read by theblock 248 is to be used in the page currently under consideration, ablock 256 duplicates the data representing the page remaining afterexecution by the block 244 to initiate development of one of the files130 or 132. In the first pass through the program of FIG. 10 c, and inconnection with the example of FIGS. 6 a and 6 b, the block 256 createsthe file 130 and develops page data representing a first version of thepage P1-a and adds further variable information to such page data duringimmediately succeeding passes through the program. Thereafter, datarepresenting the remaining pages P1-b, P1-c and P4-a through P4-c arecreated and variable information is added to such pages serially duringsubsequent passes.

A block 258 checks to determine whether there are any image boxes on thepage and, if so, a block 260 selects a first image box. A block 262 theninserts the image identified by the database field into the image box. Ablock 264, FIG. 10 d, checks the subname to determine whether the block162 of FIG. 9 has indicated that the image should be sized to fit theimage box. If this is true, a block 266 performs the scaling. Otherwise,a block 268 positions the image in the image box at the positionspecified by the user and a block 270 checks to determine whether allimage boxes have been processed. Control also passes from the block 266directly to the block 270, thereby skipping the block 268. If not allimage boxes have been processed, a block 272 selects a next image box onthe page and control returns to the blocks 262-270 so that remainingimage boxes are serially processed.

Once the block 270 determines that all image boxes have been processed,or immediately following the block 258 of FIG. 10 c if no image boxesare found on the page, a block 274 checks to determine whether there areany text boxes on the page and, if so, a pair of blocks 276, 278 selecta first text box and a first insertion point in such box. Blocks 280,282 and 284 serially insert text data stored in the database 108 at theappropriate insertion points in the text box. Once all of the variabletext data have been inserted into the text box, a block 286 recomposesall text in the text box so that the text obtains a neat finishedappearance. The recomposition process is automatically undertaken by theQuarkXPress® program once the variable information is inserted into eachtext box. The recomposition process is responsive to the user commandsas applied to the template file page, such as left, right, center, orfull justification, hyphenation and the like. Following the block 286, ablock 288, FIG. 10 e, checks to determine whether there are remainingtext boxes to be processed on the page and, if so, a block 290 selectsthe next text box on the page and control returns to the blocks 278-288to insert text information into such text boxes.

Once the block 288 determines that all text boxes for the page have beenprocessed, the programming required to produce one of the pages of thefile 134 of FIG. 5 having variable information only thereon is complete.A block 292 then determines whether all records in the database havebeen considered for inclusion in additional variable pages of the file134 to be produced. If not all records have been considered, controlreturns to the block 254, FIG. 10 c, where the next database record isidentified and read. On the other hand, if all pages of the file 134have been produced by considering all records in the database 108, ablock 294 converts the file data into Postscript® or another PDL formatto create the variable page file 137 of FIG. 5. Also, an INI file iscreated as before, except that the “duplex” or “twinplex” parameter isset to command simplex printing only. If necessary or desirable, shouldthe press run length exceed a certain limit, the programming may bemodified to create more than one variable page file for each variablepage of the template file.

Following the block 294, a block 296 checks to determine whether thereare other variable pages in the stripped variable page file to beprocessed. If this is true, a block 298 retrieves a copy of the strippedvariable file, selects the next variable page therein and deletesremaining pages therefrom. Control then returns to the block 246 of FIG.10 c. In the example of FIGS. 6 a and 6 b, the back cover P4 and thecorresponding pages of the remaining books are now selected forprocessing. In the fashion noted above, a file representing the variableportions of such pages is produced by developing the file representingthe pages P4-a through P4-c and inserting the database information intosuch file to obtain the variable page file 136 and the PDL version 138.

Following generation of the variable page files 134, 136, and 137, 138control passes to a block 300 which checks to determine whether a presscommand file has already been created. If not, a file is created by ablock 302 having placeholder comments indicating where in the presscommand file individual press commands are to be placed for each book tobe produced. The press command file may also include data from one ormore fields of the database 108 identifying an intended recipient ofeach book to be produced to assist in reproducing books found to bedefective or to produce sample books. At this point, the press commandfile for the example of FIGS. 6 a and 6 b may be as follows (using datafrom the sample database set out above):

;RECORD1

;:WILLIAM DOE:606248923

;ENDRECORD

;RECORD2

:HUGH JORGENSEN:606248923

;END RECORD

;RECORD3

;:JAY P. MORGAN:606248924

;END RECORD

Following the block 300 (if the press command file already exists) orthe block 302 a block 304 selects the first database record and acorresponding first record in the press command file. A block 306 thenchecks to determine whether the template file currently being processedincludes the selected database record. If not, a block 308 determineswhether all pages have been processed, and if this is not the case, thenext record in the database 108 and a corresponding record in the presscommand file are selected. Control then returns to the block 306. If theblock 306 ascertains that the template file includes the selectedrecord, a block 312 inserts an indication of the section number in thepress command file at an appropriate point if the section number is notalready present. If the section number is present already, the presscommand identified by the section number entered by the user at theblock 176 is identified to be overwritten at a later point. The presscommand file now appears as follows for the example of FIGS. 6 a and 6b:

;RECORD1

;:WILLIAM DOE:606248923

;SECTION 1

;ENDSECTION

;ENDRECORD

;RECORD2

;:HUGH JORGENSEN:6062488923

;SECTION 1

;ENDSECTION

;END RECORD

;RECORD3

;:JAY P. MORGAN:606248924

;SECTION 1

;END SECTION

;END RECORD

Following the block 312, a block 314, FIG. 10 f, selects a first page ofthe section and a block 316 checks the state of a flag stored in thememory 53 to determine whether a simplex or duplex job has beenrequested. If a simplex job has been requested, the file name and pagenumber of the master page file and, if variable information is to appearon the page, the file name and page number of the variable page file forthe selected page are stored as a single set pair in the memory 53 by ablock 318. The determination of whether variable information is toappear on the selected page is accomplished by summing the contents ofthe variable image box counter and the variable text box counter asincremented by the blocks 220 and 234 of FIG. 10 b.

A block 320 checks to determine whether all pages have been processedand, if not, the next page is selected by a block 322 and controlreturns to the block 316 for processing of such page. If all pages havebeen processed, control passes to a block 324 which determines whetherall database and press command records have been processed. Control alsopasses to the block 324 if the block 308 determines that all pages havebeen processed. If not all records have been processed at this point,control returns to the block 310 where the next records in the databaseand press command file are selected.

If the block 324 determines that all records for the current sectionhave been processed, a block 326 determines whether another section isto be processed and, if so, control returns to the block 170 of FIG. 10a. If there is not another section to be processed, the press commandfile has been fully assembled, and hence the process terminates.

If the block 316 determines that a duplex job is to be effected, controlpasses to a block 328 which stores in the memory 53 a commandidentifying the file names and page numbers of the master page file (aswell as corresponding information relative to variable page files, ifvariable information is to appear) as two-set pairs. Control from theblock 328 then passes to the block 320 described above.

The result of the programming of FIGS. 10 a-10 f is a press command filehaving a sequence of press commands which cause printing of pages in adesired order. In order to print the sample pages of FIGS. 6 a and 6 b,the press command file would read as follows:

BOOK A

;RECORD1

;:WILLIAM DOE:606248923

;SECTION 1

“file.m”1@“file.v1”1|“file.m”2

“file.m”3|“file.m”4@“file.v4”1

;ENDSECTION

;ENDRECORD

;RECORD2

;:HUGH JORGENSEN:606248923

;SECTION 1

“file.m”1@“file.v1”2|“file.m”2

“file.m”3|“file.m”4@“file.v4”2

;ENDSECTION

;ENDRECORD

;RECORD3

;:JAY P. MORGAN:606248924

;SECTION 1

“file.m”1@“file.v1”3|“file.m”2

“file.m”3|“file.m”4@“file.v4”3

;ENDSECTION

;ENDRECORD

ENDBOOK

PRINTRUN R

BOOK A

ENDPRINTRUN

In the foregoing example, “file.m” is a file name identifying the masterpage file 122 and “file.v1” and “file.v4” are file names identifying thevariable page files 137 and 138, respectively. The number following eachfile name designates a particular page of the file identified by thefile name. Thus, for example, “file.m”1 designates the first page of themaster file “file.m” and “file.v1”2 designates the second page of thevariable page file “file.v1.” The @ sign means to associate the pages ofthe files linked by such sign (i.e. overlay the variable pages on themaster pages). The vertical line in the commands indicates that thepage(s) on the left side of the vertical line are to be printed on thefront side of a piece of paper whereas the page(s) on the right side ofthe vertical line are to be printed on the reverse side of the piece ofpaper. In an example of simplex printing, no file name would appear tothe right of the vertical line in each command.

FIG. 11 illustrates the programming implemented by the control unit 52to generate a page description language instruction set specifying whichpages should be printed and how the pages should be positioned (orimposed) for printing. The page description language instruction set maybe incorporated into the press command file 140 or may be provided as aseparate file to the print system 79. For purposes of illustration, thepage description language instruction set is written in Postscript® inthe format dictated by the Xerox DocuPrint printer. Further, theinstruction set is directed to books printed in “saddle stitch”imposition format (i.e. 2 pages on each side of sheet) as explained inconnection with FIGS. 6-8. It is understood, however, that the inventioncould easily be modified for use with a different demand printer (i.e.the Xeikon Barco printer) and/or imposition format (i.e. 4 pages on eachside of sheet).

Referring to FIG. 11, the programming begins at a block 340 whichprompts a user to specify certain information to be used to paginate thebook. A variable (“MAXPGS”) representing the maximum number of suppliedpages that may or may not be assembled into a single book during the jobis specified together with the identification of a filler page that mayor may not be printed and assembled in a book either on a left-hand or aright-hand portion thereof. Also, the user is prompted to specify foreach page whether such page will be forced to be on the left side of abook, the right side of a book or will not be forced to a particularbook side. In the event a page is to be forced to a side, the user isprompted to specify the page file name and page number for a filler pageto precede the forced page. Still further, the user is prompted tospecify for each page whether such page is:

1) A Master Page—contains the same information and is included in everybook;

2) An Always Variable Page—contains variable information and is includedin every book; or

3) A Selectively Variable Page—contains variable information and isselectively included in selected books.

In so specifying the foregoing, the user creates a pagination file(called, for example, *.PAG, where * indicates a file name selected bythe user). A sample window generated by the block 340 to prompt a userfor the information needed to create the pagination file is shown inFIG. 12.

Referring again to FIG. 11, following the block 340, a block 342 opensthe press command file 140 and a block 344 selects the appropriatedatabase files, including the variable information file (*.vars), thepagination file (*.pag), and (optionally) a barcode file. As set forthabove, the *.vars file is a temporary file of pairs of page numbers anddatabase column numbers that indicate where in the database variableinformation for the page comes from.

The barcode file is a page description language file (for example, aPostScript® file) which contains instructions for printing thesequential page numbers and/or a tracking bar code on the pages of thecompleted book. The barcode file will be explained in detail below.

The programming then proceeds to the loop containing blocks 346, 348,350, 352 and 354. The block 346 takes each record (or book) in the presscommand file 140 in sequential order. For each record, the block 348determines which pages should be printed to generate that particularbook. Next, the block 350 determines whether the pages to be printedshould be forced to the right hand or left hand side of the book and theblock 352 “pads” the pages to be printed to be a multiples of the numberof pages to be printed on a sheet (in our example, 4) by addingappropriate filler pages. Next, the block 354 generates the PostScript®instruction set and the programming returns to the block 346 to retrievethe next record in the press command file 140. The loop repeats for eachrecord in the press command file 140.

FIG. 13 illustrates in detail the programming steps implemented by theblock 348 of FIG. 11, which determines which pages should be printed fora particular record in the press command file 140. A block 360 firstretrieves the first page in the record. A decision-making block 362 thendetermines whether the page is from a new file that is to be“imposed-on-the-fly with offsets.” (Imposition-on-the-fly with offsetsis one of the imposition formats of the present invention, which will beexplained in detail below). If yes, a block 364 calculates and saves theoffsets for all the pages in the file. After the block 364 calculatesand saves the offsets or if the block 362 is false, a decision-makingblock 366 then determines whether the page is a master page (i.e. doesnot include any variable information placeholders). If the page is amaster page, the page should always be printed and a block 368 “marks”the page to be printed. The block 368 may “mark” the page by adding itto a page print array. The page print array contains the page number anda marker to indicate the disposition of the page. For example, pagesthat should not be printed are designated with a “0”; master pages(always printed) are designated with a “1”; and variable pages to beprinted are designated with a “2”.

If the block 366 determines that the page is not a master page (i.e.it's a variable page), a decision-making block 370 determines whetherthe variable page should be printed at all times. (This was designatedby the user at the block 340 in FIG. 11 during creation of thepagination file). If yes, the block 368 marks the page to be printed. Ifno, a decision-making block 372 determines whether the page has anyvariable placeholders with valid data. In other words, the block 372determines whether there is any variable information from the databaseto be printed on the page. If yes, the block 368 marks the page forprinting. The program then returns to the block 360 to retrieve the nextpage from the record until all the appropriate pages have been markedfor printing.

FIG. 14 illustrates in detail the programming steps implemented by theblock 350 of FIG. 11 to determine whether the pages should be forced tothe left or right hand side of the book. A block 380 first initializes aleft/right (L/R) counter variable to its default value of right becauseit is assumed that the first page of the book will be one the rightside. Next, a block 382 retrieves the first page from the record that ismarked “should print” and a block 384 determines whether the user hasspecified whether the page should be forced to the left or right side.(This was designated by the user during creation of the pagination fileat block 340 of FIG. 11). If the user has not specified that the pageshould be forced, a block 386 flip-flops the L/R counter such that if itwas set to right it is changed to left and if it was set to left, it ischanged to right and the program returns to the block 382 to retrievethe next “should print” page in the record.

Alternatively, if the block 384 determines that the user has specifiedthat the page should be forced left or right, a block 388 determineswhether the user specification matches the orientation of the page (i.e.is it the same as the L/R counter). If yes, the block 386 flip-flops theL/R counter and returns to the block 382 to retrieve the next “shouldprint” page in the record. Otherwise, a block 390 marks an appropriatefiller page (which was identified by the user during creation of thepagination file) to be printed and the program returns to the block 382to retrieve the next “should print” page in the record.

FIG. 15 illustrates in detail the programming steps implemented by theblock 352 of FIG. 11 to “pad” the pages into a multiple of the number ofpages to be printed on a sheet. In our example, using “saddle stitch”imposition, four pages are printed on a sheet (2 pages per side).Therefore, filler pages may need to be added to ensure that the totalnumber of pages in the book is a multiple of 4. A block 392 first countsthe number of pages in the record that have been marked to print. Thisincludes all the master and variable pages that were marked by the block368 of FIG. 13 as well as any filler pages that were marked by the block390 of FIG. 14. Next, a block 394 determines whether the total number ofpages is a multiple of 4. If not, a block 396 adds the appropriatenumber of filler pages to make the total number of pages a multiple of4. For example, if the block 392 determines that 18 pages are marked toprint, the block 396 will add 2 filler pages to make the total number ofpages in the book equal to 20 (a multiple of four). The program thenreturns to the block 354 of FIG. 11 which generates the PostScript®instruction set.

The PostScript® instruction set specifies how the pages marked to printshould be positioned (or imposed) for printing. In our example, for a“saddle-stitch” imposition format, and assuming a 12 page book, theblock 354 generates an instruction specifying that the pages should bepositioned as shown in the following table: Sheet No. Side No. Left SideRight Side 1 1 Page 12 Page 1 1 2 Page 2 Page 11 2 1 Page 10 Page 3 2 2Page 4 Page 9 3 1 Page 8 Page 5 3 2 Page 6 Page 7It is understood that a different instruction set could be generated (byan imposition program) to impose and print the pages in a differentformat (i.e. four pages per side) or alternatively, a different numberof total pages.

After the block 354 generates the imposition instruction set, the pagesare imposed and printed according to an imposition procedure of thepresent invention. The first imposition procedure of the presentinvention utilizes an artificial PostScript® operator called “GetTIFF”,which is recognized by the Xerox DocuPrint RIP, wherein page files arepreprocessed to TIFF (“tagged image file format”) format before beingprovided to the RIP. The second imposition procedure of the presentinvention (referred to as “imposition-on-the-fly”) involves downloadingimposition programs to the RIP which redefine various PostScript®operators to automatically position pages while each page is beinginterpreted.

A user is prompted to specify various information needed for impositionand printing, including the sheet size (i.e. 11×17), imposition style(imposition-on-the-fly or GetTIFF), finishing style (online or offline),the output device (i.e. Xerox DocuPrint or Barco Xeikon) and the name ofthe directory where the master and variable page files are stored. Asample window to prompt a user to provide this information is shown inFIG. 16.

GetTIFF Imposition

A TIFF (tagged image file format) file is a bitmap representation of apage in the same screen format as the print engine. Several commerciallyavailable RIPs (such as Image Alchemy or TranverterPro) process pagesrepresented in a page description language format to TIFF format. TheXerox DocuPrint RIP recognizes an artificial PostScript® operator called“GetTIFF” which retrieves a specified TIFF file and quickly processesthe file for rendering by the DocuPrint demand printer. (Other demandprinter RIPs, including the Barco Xeikon, may also be modified torecognize a GetTIFF-type operator).

In a preferred embodiment of the present invention, the master page PDLfiles 122 and the variable page PDL files 137, 138 are preprocessed toTIFF format. Because the Xerox DocuPrint system allows for only oneinput data stream (as opposed to the Barco Xeikon system which allowstwo data streams—master and variable), the master page PDL files 122 andthe variable page PDL files 137, 138 may be premerged. This may beaccomplished by forcing all of the master data onto the variabletemplate files. After the master and variable pages are merged, theinstruction set and GetTIFF operator are used to quickly impose andprocess the pages for printing.

Alternatively, the master and variable data streams may be overlayed byfirst processing the master pages and then overlaying the variable pagesonto the master pages.

FIG. 17 illustrates programming which may be executed to facilitateconversion of the page files into TIFF format. The programming begins ata block 397 which opens the press command file stored in the memory 53.A block 398 then prompts a user to specify options which are available.The options include the ability to convert only master page files, onlyvariable page files or both master and variable page files into bitmapformat. A block 399 then selects the first line in the press commandfile having at least one file name therein. Thereafter, a block 400selects a first file name and a block 401 checks a file list stored inthe memory 53 to see if the file name has been previously placed in thelist. If this is not the case, then this is the first time the file namehas been encountered in the programming of FIG. 17. Thus, a block 402adds the file name to the file list and a block 403 checks theuser-specified options set by the block 398 to determine whether thefile should be converted into TIFF format. If so, a RIP list stored inthe memory 53 is updated by adding the file name thereto (block 404) andcontrol passes to a block 405. Control also passes to the block 405 fromthe block 403 (bypassing the block 404) if the file is not to beconverted into TIFF format, and from the block 401 if the file namecurrently under consideration is already in the file list.

The block 405 checks to determine whether the end of the current line inthe press command file has been reached. If not, a block 406 selects thenext file name in the line and control returns to the block 401.

If the block 405 determines that the end of the current line in thepress command file has been reached, a block 407 checks to determinewhether the end of the press command file has been reached. If not, ablock 408 selects the next line in the press command file having atleast one file name and control returns to the block 400. On the otherhand, if the end of the file has been reached, a block 409 causes theRIP 82 (or another RIP) to convert the files identified in the RIP listinto TIFF format.

The programming of FIG. 17 thus facilitates conversion of files to TIFFformat as required by the print system 79.

Referring to FIG. 18, if the user specified GetTIFF imposition and afterthe page files have been RIPped to TIFF format by the programming ofFIG. 17, a block 410 retrieves the first page pairing from theinstruction set (in our example, page 12 as the left hand page and page1 as the right hand page). A block 412 then retrieves a reference to thepage description of the left hand page in TIFF format from the page fileand provides it to the RIP 82. Assuming the default offset is positionedat the left side of the sheet, the left hand page is positioned on theleft side of the sheet.

A block 414 then moves the offset to position the next page onto theright side of the sheet. A block 416 retrieves the reference to the pagedescription in TIFF format of the right hand page from the page file andprovides it to the RIP 82. Next, a block 418 may add page numbers and/ora bar tracking code to the sheet, as explained-below. The program thenreturns to the block 410 to retrieve the next page pair from theinstruction set and the program repeats until all pages and all bookshave been processed.

After all pages have been processed, they are RIPped and printed by thedemand printer 84 in accordance with the initialization (INI) file,which was created by the block 212 (FIG. 10 b).

If, for example, the demand printer is a DocuPrint (i.e., no INI filewas created), the pages are submitted to the queue (which contains thesame parameters as the INI file) for RIPping and printing.

A partial Postscript® instruction set for printing the 12-twelve pagebrochure in accordance with the table above implementing the GetTIFFimposition according to FIG. 18 is set forth below: << /PageSize [1224792] % set sheet size >> setpagedevice % (11 × 17) (VERON12.V01_dir/  %get left page  VERON12.V01.00000002.tiff) GetTIFF 612 0 translate % moveto right (VERON01.V01_dir/   % get right page VERON01.V01.00000002.tiff) GetTIFF showpage (VERON02.M_dir/   % getleft page  VERON02.M.00000002.tiff) GetTIFF 612 0 translate % move toright (VERON11.V01_dir/   % get right page  VERON11.V01.00000002.tiff)GetTIFF showpage . . . (VERON06.M_dir/   % get left page VERON06.M.00000004.tiff) GetTiff 612 0 translate % move to right(VERON07.V03_dir/   % get right page  VERON07.V03.00000003.tiff) GetTiffshowpage % reset to left

In the instruction set, the “VERON*.*_dir/VERON*.*” indicates thedirectory and filename where the page descriptions are located. Thesuffix “.M” indicates a master page and the suffix “.V______” indicatesa variable page (with the version number of the variable page to beprinted). The suffix “______.tiff” is the file name created by the RIPwhich converted the page files to TIFF files and indicates that thefiles are in TIFF format. The artificial Postscript® “GetTIFF” operatorinterprets the TIFF files. The “612 0 translate” command moves theoffset to the right hand side of the sheet (block 414) and thePostScript® showpage operator transmits the page to the demand printer84 for rendering, prepares for interpreting the next page descriptionand resets the offset to the lefthand side.

Optionally, the block 418 may print page numbers and/or a bar trackingcode onto the sheets printed by the demand printer 84. This may beaccomplished by adding the following additional PostScript® code beforethe showpage operator in the instruction set shown above: /C39P24Dm 24selectfont % add bar code info 30 4.5 sub 18 translate 90 rotate %position on 0 0 moveto % side of sheet (1.12) show % indicates sheet 1of 12 % /Helvetica 12 selectfont % add page numbers 320 780 moveto %center in middle of left page (12) show % print page “12” −320 780moveto % center in middle of right page (1) show % print page “1”The first section of code provides the command for printing a bar code(indicating for example, the page number and the total number of pagesin the book). The second section of the code prints page numberscentered at the bottom of each page. A similar technique could be usedto do any “post page” modifications, such as watermarking samples or QCbooks, adding variable printers marks or the like.Imposition-on-the-Fly

The user may also specify that the pages be imposed and printed usingthe imposition-on-the-fly technique of the present invention. Thistechnique positions the pages while the pages are being interpreted bythe RIP. FIG. 19 is a more detailed block diagram of the print system 79shown in FIG. 4. The PDL master page files 122 and the PDL variable pagefiles 137, 138 may be combined into merged PDL files (such as mergedPostScript file(s) 450), which are then provided to the print system 79,comprised of RIP 82, collator 81, press controller 80 and demand printer84. The press command file 140, which includes the instruction set forspecifying how pages should be imposed, is also provided to the printsystem 79.

Alternatively, as described above, the master page files 122 and thevariable page files 137, 138 may be provided separately to the printsystem 79 and overlayed.

The print system 79 may also include a raster memory 452 associated withthe RIP 82 and the demand printer 84. The RIP 82 generates a rasterdescription of the “current page” being interpreted, which may be storedin the raster memory 452 or provided to the demand printer 84 forrendering. The demand printer 84 physically renders pages 454 from themerged PostScript® file 450 onto a “flat” (or other medium) 456.

For purposes of illustration, it is assumed that the RIP 82 interpretsthe widely used PostScript® PDL language. (PostScript® is a registeredtrademark of Adobe Systems, Inc.) The PostScript® language is fullydescribed in the PostScript® Language Reference Manual, Second Edition(1990), from Adobe Systems, Inc., which is incorporated herein byreference. Certain imposition-on-the-fly procedures 454 according to thepresent invention are downloaded to the RIP 82. (The procedures 454include, for example, ImposeJob, ImposeFile and various redefinedPostScript® operators which are described in detail below). Theimposition-on-the-fly procedures 454 will be used by the RIP 82 toprocess the instruction set and the page descriptions contained in themerged PostScript® files 450 to efficiently transmit pages for renderingby the demand printer 84. (For ease in illustration, it is assumed themaster and variable page files were premerged into merged file 450. Itis understood, however, that the master and variable page files couldalso be overlayed.)

PostScript® Background

In order to facilitate the explanation of imposition-on-the-flyprocedures of the present invention, some background regarding thePostScript® language is provided. Further background details may befound in the PostScript® Language Reference Manual, Second Edition(1990), from Adobe Systems, Inc., which was previously incorporated byreference.

The RIP 82 manages four different stacks, which are “last-in-first-out”(LIFO) data structures. These stacks include:

(1) an Operands Stack which holds (i) the input operands to variousPostscript® operators, and (ii) the results of the operations;

(2) an Execution Stack which is controlled by the RIP 82 and which holdsexecutable objects (i.e. procedures and files) that are in stages ofexecution;

(3) a Dictionary Stack which includes (i) a read only dictionary(“systemdict”) which defines the implementation of the variousPostScript® operators, (ii) a writable dictionary (“userdict”) whichstores all other definitions, and (iii) specialized dictionaries createdby the user (e.g., an imposition dictionary);. and

(4) a Graphics State Stack which is used to store graphics information,such as the parameters of the demand printer 84.

The PostScript® language is device independent such that the pagedescriptions contained in the merged PostScript® file 450 are specifiedin a coordinate system (called “user space”) that is independent of theparticular demand printer 84. The coordinate system (called “devicespace”) used by the demand printer 84 varies depending on the particulardemand printer 84 (the “current device”) which is specified forrendering the current page. In order to render the pages described inthe merged Postscript® file 450, the page descriptions (specified inuser space) may be transformed to the current device space by a CurrentTransformation Matrix ([CTM]).

The PostScript® language uses the Current Transformation Matrix ([CTM])to describe scaling, rotation, and translation of the page from userspace to device space. For mapping the point (x, y) in user space to thepoint (x′, y′) in device space:  [ (FileName)  [ { user procedure 1 }  page# { operands to setvirtualdevice }   { FileObject   offset   setfileposition }  ]  [ { user procedure 1 }   page# { operands tosetvirtualdevice }   { user procedure 2 - barcodes, watermarks, etc. } ] ]where a, b, c, and d determine the extent of scaling and rotation andwhere t_(x) and t_(y) determine the extent of translation.

The RIP 82 also maintains a data structure, called the “graphics state,”that holds various graphics control parameters, including the [CTM]. Thegraphics state also includes (i) a clipping path, which defines therendering area in the raster memory 452 for the current page; (ii) fontand line definitions; (iii) a color space (such as DeviceGray, RGB, CMYKor CIE); and (iv) other graphics control parameters.

The PostScript® language includes several operators for setting up thecurrent demand printer 84 to fulfill the processing requirements of thepage descriptions contained in the merged PostScript® file 450. Thecurrent device setup includes establishing the Current TransformationMatrix ([CTM]) for the current demand printer 84. The defaulttransformation from user space to device space for the current device isspecified by a “system default matrix.” The system default matrix may begenerated by the PostScript® language, for example, by a defaultmatrixoperator. The [CTM] may be considered an alteration of the systemdefault matrix.

Once the current demand printer 84 has been set up, the RIP 82 can beginto interpret the page descriptions in the merged PostScript® file 450.For each page in turn, everything that is to appear on that page(including text, graphics, and images) is “painted” into the rastermemory 452 and stored and/or rendered by the demand printer 84.

In the merged PostScript® file 450, each description of a page to berendered includes a PostScript® showpage operator. The showpageoperator, which is generally included at the end of each pagedescription, is used to transmit the raster description of the currentpage (saved in the raster memory 452) to the demand printer 84 forphysical rendering of the current page. In general, the showpageoperator transmits the contents of the raster memory 452 to the demandprinter 84, then erases the current page from the raster memory 452 andpartially resets the graphics state in preparation for interpreting thenext page description in the merged PostScript® file 450.

In level 2 postScript® implementations, the function of the showpageoperator is controlled by an EndPage procedure and a BeginPage procedurethat are defined according to the current demand printer 84. In general,the EndPage procedure specifies the disposition of the current page inthe raster memory 452 and the BeginPage procedure sets up and marks thebeginning of the next page description to be interpreted. Theseprocedures may be defined, for example, by a level 2 setpagedeviceoperator which sets up the graphics state for the current demand printer84 (the “current graphics state”).

During normal operation, the level 2 showpage operator provides twooperands to the EndPage procedure: a reason code and Pagecount. Thereason code operand specifies whether the EndPage procedure is beingcalled by the showpage operator, by a copypage operator, or during adevice deactivation. When the EndPage procedure is called by theshowpage operator, the reason operand is set to 0. The Pagecount operandis the number of executions of the showpage operator that have occurredsince the current device was activated, not including the presentexecution. Thus, Pagecount is equal to the number of pages that havebeen rendered prior to the current page. After the EndPage procedure isexecuted, Pagecount is incremented by one and is provided as an operandto the BeginPage procedure.

The operation of the level 2 showpage operator is illustrated in theflowchart of FIG. 20. A block 500 first sets the reason code operandequal to zero to specify that the EndPage procedure is being called bythe showpage operator. A block 502 then calls the EndPage procedure,which consumes the reason code and PageCount operands and returns aboolean result that specifies the disposition of the current page in theraster memory 452. During normal operation, the EndPage procedurereturns true during execution of the showpage or copypage operators(causing a physical page to be produced) and returns false during devicedeactivation. A decision-making block 504 determines whether the resultreturned from the EndPage procedure is true or false.

If the EndPage procedure returns “true”, a block 506 transmits thecontents of the raster memory 452 to the demand printer 84 forrendering. A block 508 then clears the raster memory 452 by executing aprocedure similar to a PostScript® erasepage operator. Under normaloperation, the EndPage procedure returns true if it is called by theshowpage or copypage operator. Thus, the showpage and copypage operatorscause the contents of the raster memory 452 to be transmitted to thedemand printer 84 for rendering.

If the EndPage procedure returns a “false”, the showpage operator doesnot perform either of the functions of the blocks 506 and 508 (i.e., nopage is rendered), but skips to a block 510. The block 510 executes aprocedure similar to a PostScript® initgraphics operator which resetsthe [CTM], the clipping path, and other graphics parameters to thedefault values for the current demand printer 84, thus setting up thegraphics state for composing the next page. The clipping path definesthe rendering area for the current page stored in the raster memory 452.

A block 512 then increments the Pagecount operand by one and a block 514calls the BeginPage procedure with Pagecount as an operand. TheBeginPage procedure marks the beginning of the next page in the mergedPostScript® file 450 to be interpreted by the RIP 82.

The standard operation of the level 2 showpage operator illustrated inFIG. 20 may be represented by the following PostScript® pseudo code:/showpage {  /reason 0 def % reason = 0 for % showpage  pagecount reasonEndPage % call EndPage % procedure   { transmit contents of % do theselines    raster memory to % only    demand printer % {close oversizebrace} if Endpage    erasepage } if % returns true  initgraphics % setdefault graphics % state  /pagecount pagecount 1 add def % increment %pagecount  pagecount BeginPage % call BeginPage % procedure } defThe Imposition-On-The-Fly Procedures

The imposition-on-the-fly procedures of the present invention create alayer on top of the demand printer, called a “virtual device.” Thedesired position (scale, orientation and size) of a page to be printedby the demand printer is specified by a procedure (called“setvirtualdevice”) which establishes the virtual device for that page.Thus, from the standpoint of the PostScript® program, the [CTM] is thesame as the system default matrix and every page begins with a [CTM]mapping user space coordinates to the lower left corner of the outputdevice. The [CTM] can be explicitly manipulated as if each PostScript®page were imaged on a distinct, but identical, physical page.

Thus, when imposing and rendering a selected page from the mergedPostScript® file 450, the current output device (i.e. the demand printer84) is defined as the virtual device. In general, the virtual device fora selected page is the same size as the page and is positioned at theplace on the flat 456 where the page is to be rendered.

The virtual device is established by setting the current transformationmatrix ([CTM]) to properly position the page. A clipping path, whichdefines the rendering area in the raster memory 452, is then createdaround the border of the page. Thus, the RIP 82 “sees” the positionwhere the page is to be rendered as the current output device.

For pages in the merged PostScript® file 450 that will not be renderedon the current flat 456 (i.e. are not included in the current book), thecurrent output device (the demand printer 84) is defined as ascaled-down virtual device for the next page to be imposed and renderedon the flat. The scaled-down virtual device allows any intervening pagesnot to be imposed on the flat to be quickly interpreted by the RIP 82.

The imposition-on-the fly procedures include the setvirtualdeviceprocedure, which establishes the virtual device for the next page torendered on the flat 456 and an EnableVirtualDevice procedure which setsup the showpage operator to support virtual devices. The EndPage andBeginPage procedures that are invoked by the showpage operator are alsoredefined. These procedures will be described in detail below.

The Imposition-on-the-Fly Instruction Set:

Preferably, the instruction set for implementing imposition-on-the-flyby creating the virtual device for pages to be rendered on the flat areinput to the RIP 82 in the below-described format. However, the presentinvention may be modified to properly impose different instruction setformats.

The imposition-on-the-fly instruction set contains the name(s) of themerged PostScript® file(s) 450 that will be interpreted by the RIP 82and rendered by the demand printer 84. These file names are associatedwith entry lists (stored in arrays) containing one or more entries,wherein each entry contains the following information:

1) A first user procedure—The user procedure may contain variousinstructions, including comments, printer's marks (such as barcodes orwatermarks) or other information. (The user procedure may also be nulland is not essential to the imposition-on-the-fly procedures of thepresent invention).

2) A page number—The page number is the sequential number of the pagedescription in the merged PostScript® file 450 of the page to berendered on the flat 456. The merged PostScript® file 450 is assumed tocontain page descriptions in sequential order, wherein the first pagedescription is page “0.”

3) Operands to the setvirtualdevice procedure—As explained in detailbelow, the setvirtualdevice procedure establishes the appropriatevirtual device as the current output device for a particular page. Thesetvirtualdevice procedure requires the following three operands, whichare included in each entry in the entry list:

-   -   i) the scaling, translation and rotation factors which will be        used to generate a “virtual [CTM]” which will properly position        the selected page on the flat 456. These factors are listed as        follows: [scale_x scale_y translate_x translate_y rotate];    -   ii) the user space coordinates of the lower-left and upper-right        corners of the actual rendering area of the next page to be        rendered on the flat 456. These corner coordinates will be used        to generate a clipping path around the border of the page in the        raster memory 452. The corner coordinates are listed as follows:        [ClipllX ClipllY ClipurX ClipurY]; and    -   iii) the size (width and length) of the page to be rendered on        the flat. The page size is listed as follows: [PageX PageY].        (The page size is not necessarily equivalent to the clipping        path defining the rendering area of the page, as many demand        printers are unable to place marks at the extreme edges of the        page).

4) A second user procedure (“offsets”): Like the first user procedure,the second user procedure may contain comments, printer's marks(barcodes, watermarks, etc.) or other information or may be null. In apreferred embodiment, however, for the first page on the flat, thesecond user procedure is used to “offset” the program to the next pageto be rendered on the flat.

For example, the merged PostScript® file generally contains many, manypages because it includes separate page descriptions for each variablepage. Assume a simple four page book with three master pages and onlyone variable page. The book may be sent to 1,000 different people, withdifferent variable information for each person. Thus, the mergedPostScript® file contains 1,003 page descriptions−3 master pages and1,000 variable pages. Imposition-on-the-fly with offsets allows forquick printing of the books because it “skips over” (i.e. does not RIP)the 999 variable pages that will not be included in each book.

For imposition-on-the-fly with offsets, the second user procedure forthe first entry in the instruction set contains a file object, an offsetposition and the PostScript® setfileposition operator. The offsetposition points to the next page description in the file that is to beincluded on the flat. (The offset positions were calculated and saved bythe block 364 of FIG. 13.) The setfileposition operator reopens thecurrent merged PostScript® file 450 to that offset position.

Thus, the PostScript® instruction set format for imposition-on-the-flyimposition of the present invention is as follows: [ (FileName)  [ {user procedure 1 }   page# { operands to setvirtualdevice }   {FileObject   offset    setfileposition }  ]  [ { user procedure 1 }  page# { operands to setvirtualdevice }   { user procedure 2 -barcodes, watermarks, etc. }  ] ]

A sample imposition-on-the-fly with offsets instruction set is attachedas Appendix I. The Appendix I instruction set also includes code incertain second user procedures to print a barcode.

Explanation of Variables:

The variables used by the imposition-on-the-fly procedures may beconveniently defined and stored in a user dictionary (called, forexample, “impositiondict”). These variables include:

1) PageOffset—the cumulative number of pages from any previousPostScript® files that have been interpreted in accordance with theimposition-on-the-fly procedures of the present invention. Initially,Pageoffset is set to −1 (no previous files (or pages) have beeninterpreted).

2) CurrentPage—the number of the next page in the current mergedPostScript® file 450 that is to be rendered on the current flat 456.CurrentPage is initially set to 0.

3) LastPage—the number of the last page in the current mergedPostScript® file 450 that is to be rendered on the current flat, whichis equal to the page number in the last entry of the entry list.LastPage is initially set to 1 and is used to determine how many pagedescriptions in the merged PostScript® file must be interpreted in orderto properly render all of the selected pages on the current flat.

4) PageCount—the number of times that the showpage operator has beenexecuted (initially 0). In level 2 PostScript® implementations,PageCount is stored and incremented internally by the RIP 82 through theshowpage operator. However, in level 1 PostScript® implementations, thePageCount variable must be explicitly defined and incremented to emulatethe operation of the level 2 showpage operator.

5) PageList—the list of entries (page numbers and imposition procedures)contained in the entry list.

6) CurrentIndex—an index into the PageList.

7) LastIndex—the number of entries in the entry list.

8) DefaultMatrix—used to store the value of the [CTM] describing thevirtual device (the “virtual [CTM]”). The scaling, translation androtation components of the virtual [CTM] are supplied as operands to thesetvirtualdevice procedure.

9) PageX and PageY—the width and height respectively of the page to berendered on the flat 456. The values of PageX and PageY are provided ineach entry of the entry list as operands to the setvirtualdeviceprocedure.

10) DefaultPageX and DefaultPageY—the default values of the page widthand height, respectively. Their values are initially set to 8½″ (612)and 11″ (792), respectively.

11) ClipllX, ClipllY, ClipurX and ClipurY—the user space coordinates ofthe lower-left and upper-right corners, respectively, of the clippingpath defining the border of the virtual device. The values of thesevariables are also included as operands to the setvirtualdeviceprocedure.

12) Portrait—a boolean variable used to describe the page orientation ofthe current page. If Portrait is true, the current page has a portraitorientation (page width<page height). If Portrait is false, the currentpage has a landscape orientation (page width>page height).

13) DefaultPortrait—the default value for the page orientation, which isinitially set to true (portrait orientation).

14) VirtualDeviceEnabled—a boolean variable used to determine whether aprocedure called, for example, “EnableVirtualDevice,” has been executed.As explained in detail below, the EnableVirtualDevice procedure sets upthe standard PostScript® showpage operator to support virtual devices.

15) ImageDone—a boolean variable used to specify when the current flat456 has been completed. ImageDone is initially and normally set tofalse, indicating that the current flat 456 has not been completed.

A further description of the variables used is included in the followingPostScript® code, which creates the impositiondict dictionary andinitializes the variables: /impositiondict 200 dict def % createdictionary % impositiondict begin /Identity matrix def % used as inputto setmatrix /Matrix matrix def % dummy matrix for temp storage /Matrix2matrix def % dummy matrix for temp storage /Matrix3 matrix def % dummymatrix for temp storage /Matrix4 matrix def % dummy matrix for tempstorage /DefaultPageX 612 def % default page width (X) and /DefaultPageY792 def % page length (Y) (8 ½″ × % 11″) /DefaultPortrait true def  %assume page orient =  % portrait /PageOffset −1 def  % first file - noprevious  % pages /CurrentPage 0 def % initial value of page to % impose/CurrentIndex 0 def % initial value of page to % impose /LastPage2147483647 def % initial value is highest % number /PageCount 0 def %used in level 1 only /DefaultMatrix matrix % the “default” matrix forthe  currentmatrix def %  current virtual device /VirtualDeviceEnabledfalse def  % allow normal % operation /ImageDone false def % not donewith current media % Set initial job defaults /Portrait DefaultPortraitdef % default to portrait % mode /PageX DefaultPageX def % initial pagesize /PageY DefaultPageY def % /ClipllX 0 def % initial lower left/ClipllY 0 def %  and upper right /ClipurX DefaultPageX def %   cornersof /ClipurY DefaultPageY def %   clipping pathThe Redefined PostScript® Operators:

Also, before executing the imposition-on-the-fly procedures of thepresent invention, several PostScript® operators must be redefined forcompatibility with the EnableVirtualDevice and setvirtualdeviceprocedures, which will be described in detail below. The virtual device,in effect, “shields” the PostScript® program and RIP from where thepages are being painted into the raster memory 452 through the [CTM].Thus, in general, the PostScript® operators that affect the [CTM] mustbe redefined to also “shield” the PostScript® program and RIP from thefinal mapping of the page description from user space to device spacecoordinates. The PostScript® operators which must be redefined include:initmatrix transform initclip itransform setmatrix dtransformcurrentmatrix idtransform erasepage nulldevice initgraphics copypageThe standard operation of these, and all other PostScript® operators, isfully described in the PostScript® Language Reference Manual, SecondEdition (1990), from Adobe Systems, Inc., which was previouslyincorporated by reference.

The first step in redefining the above-listed PostScript® operators isto rename the standard operator, for example, “systemdict_operator,”because its definition is stored in the systemdict dictionary. This maybe implemented by the following code: /systemdict_initmatrix systemdict/initmatrix get def /systemdict_initclip systemdict /initclip get def/systemdict_setmatrix systemdict /setmatrix get def/systemdict_erasepage systemdict /erasepage get def/systemdict_initgraphics systemdict /initgraphics get def/systemdict_currentmatrix systemdict /currentmatrix get def/systemdict_transform systemdict /transform get def/systemdict_itransform systemdict /itransform get def/systemdict_dtransform systemdict /dtransform get def/systemdict_idtransform systemdict /idtransform get defAs explained below, the standard nulldevice and copypage operators arenot renamed because their standard operation will never be used inconnection with the present invention. The new definitions of theoperators, described below, are then loaded into the userdictdictionary.The Redefined initmatrix Operator:

The standard PostScript® initmatrix operator sets the [CTM] to thesystem default matrix for the current device. The initmatrix operator isredefined to set the [CTM] equal to the virtual [CTM] which defines thevirtual device.

The virtual [CTM] may be stored in the variable DefaultMatrix.

The PostScript® initmatrix operator may be redefined by the followingcode: /initmatrix {   impositiondict begin   DefaultMatrix  systemdict_setmatrix   end } bind defThe Redefined initclip Operator:

The clipping path normally corresponds to the boundary of the maximumimageable area for the current output device (the demand printer 84).The standard PostScript® initclip operator replaces the current clippingpath in the graphics state with the default clipping path for thecurrent demand printer. The initclip operator is redefined to replacethe current clipping path in the graphics state with a clipping pathdefining the border of the virtual device page.

The flowchart of FIG. 21 illustrates the program steps implemented bythe redefined initclip operator. A decision-making block 520 determineswhether a current path exists by checking for the existence of acurrentpoint. If no currentpoint is defined, a block 522 stores an emptypath in a variable called, for example, “p1.” Alternatively, if acurrentpoint is defined, a block 524 invokes a previously definedutility routine called, for example, “MakePath,” that creates a pathdescription from the current path. The block 524 then saves the currentpath description in the variable p1. The MakePath procedure, which maybe stored in the impositiondict dictionary, is similar to the level 2PostScript® upath operator and may be implemented by the following code:/MakePath {  [ {/moveto cvx} {/lineto cvx} {/curveto cvx}   {/closepathcvx} pathforall ] cvx } bind def

Next, a block 526 saves the current [CTM] and a block 528 sets the [CTM]to the virtual [CTM]. A block 530 then creates a clipping path betweenthe corners of the virtual device, which were specified by the values ofthe ClipllX, ClipllY, ClipurX and ClipurY variables provided as operandsto the setvirtualdevice procedure. A block 532 then restores the [CTM]which was saved by the block 526 and the current path saved in thevariable p1.

The PostScuipt® initclip operator may be redefined by the followingcode: /initclip  impositiondict begin   { currentpoint } stopped    {/p1 { } def } % p1 = empty path    { pop pop /p1 MakePath def}   % p1 =current   % path    ifelse  matrix systemdict_currentmatrix  initmatrix systemdict_initclip  newpath  ClipllX ClipllY moveto % create clippath ClipurX ClipllY lineto  ClipurX ClipurY lineto  ClipllX ClipurY lineto closepath  clip  newpath  systemdict_setmatrix  p1   % restore current   end    % path } bind defThe Redefined setmatrix Operator:

The standard PostScript® setmatrix operator replaces the current [CTM]in the graphics state with a matrix that is supplied on the Operandsstack. The matrix supplied on the Operands stack (“the operand matrix”)can be considered the result of the concatenation of the system defaultnatrix with an operations matrix.

The setmatrix operator is redefined to calculate the operations matrixby concatenating the operand matrix with the inverse of the systemdefault matrix. Thus,[operand matrix]=[operations matrix][system default matrix], and[operations matrix]=[operand matrix][system default matrix]⁻¹.Once the operations matrix is calculated, it is concatenated with thevirtual [CTM] (stored in DefaultMatrix) and saved as the new [CTM].Thus,new [CTM]=[operations matrix][virtual CTM].

The PostScript® setmatrix operator may be redefined by the followingcode: /setmatrix {   impositiondict begin   Matrix defaultmatrix  Matrix2 invertmatrix   Matrix3 concatmatrix   DefaultMatrix   Matrix4concatmatrix   systemdict_setmatrix   end } bind defThe Redefined currentmatrix Operator:

The standard currentmatrix operator replaces the matrix supplied on theOperands stack with the current [CTM] in the graphics state.

The current [CTM] can be considered the result of concatenating thevirtual [CTM] (saved in DefaultMatrix) with an operations matrix. Theredefined currentmatrix operator calculates the operations matrix byconcatenating the current [CTM] with the inverse of the virtual [CTM] asset forth below:[current CTM]=[operations matrix][virtual CTM], and[operations matrix]=[current CTM][virtual CTM] ⁻¹.The [operations matrix] is then concatenated with the system defaultmatrix and the resultant matrix is stored in the matrix on the Operandsstack.

The PostScript® currentmatrix operator may be redefined by the followingcode: /currentmatrix {   impositiondict begin   Matrixsystemdict_currentmatrix   DefaultMatrix   Matrix2 invertmatrix  Matrix3 concatmatrix   Matrix4 defaultmatrix   3 −1 roll  concatmatrix   end } bind defThe Redefined erasepage Operator:

The standard erasepage operator erases the entire current page stored inraster memory by painting the page white. The erasepage operator isredefined to erase only the virtual device page, which is the areadefined by the next page to be rendered on the current flat.

The erasepage operator is redefined by calling the redefined initclipoperator, described above, which establishes a clipping path around theborder of the virtual device page. The area inside the clipping path isthen painted white. The standard PostScript® gsave operator (describedin detail in connection with the optional imposition-on-the-flyprocedures of the invention) is called immediately before the redefinedinitclip operator to save the current graphics state, including thecurrent clipping path, gray level, etc. Also, after the virtual devicepage has been painted white, the standard PostScript® grestore operator(also described in detail in connection with the optional procedures) iscalled to restore the current graphics state.

The PostScript® erasepage operator may be redefined by the followingcode: /erasepage {  impositiondict begin  gsave % systemdict_gsave foroptional procs  initclip  clippath 1 setgray fill  grestore %systemdict_grestore for optional % procs  end } bind def(In the optional imposition-on-the-fly procedures, the standardPostScript® gsave and grestore operators are redefined. Thus, in theoptional procedures, the erasepage operator is redefined by calling thesystemdict_gsave and systemdict_grestore operators, as specified above.)The Redefined initgraphics Operator:

The standard PostScript® initgraphics operator resets several values inthe graphics state, including the [CTM], the current path and theclipping path, to their default values. The standard initgraphicsoperator is equivalent to the following PostScript® language sequence:

initmatrix newpath initclip

1 setlinewidth 0 setlinecap 0 setlinejoin

[] 0 setdash 0 setgray 10 setmiterlimit

The initgraphics operator is redefined to perform the above listedsequence. However, the redefined initgraphics calls the redefinedinitmatrix and initclip operators, which were described above. Thus, theredefined initgraphics operator resets the [CTM] and the clipping pathto their default values for the virtual device.

The PostScript® initgraphics operator may be redefined by the followingcode: /initgraphics {  initmatrix newpath initclip  1 setlinewidth 0setlinecap 0 setlinejoin  [ ] 0 setdash 0 setgray 10 setmiterlimit }bind defThe Redefined “transform” Operators:

The standard PostScript® transform operator transforms a supplied userspace coordinate (x,y) to the corresponding device space coordinate(x′,y′) as specified by the [CTM]. Since the [CTM] is altered during theimposition process, the transform operator is redefined to perform thetransformation as if the [CTM] had not been altered.

If a matrix operand is supplied to the standard transform operator, thetransformation from user to device space is performed according to thesupplied matrix. Thus, if a matrix operand is supplied, the transformoperator is also redefined to perform the transformation according tothe supplied matrix.

The PostScript® language includes three other “transform” operators(dtransform, itransform and idtransform) which are redefined in the samemanner as the transform operator.

The standard PostScript® dtransform operator specifies a “distance”transformation of a coordinate from user to device space according tothe [CTM] or a supplied matrix operand. In a distance transformation,the translation components (tx and ty) of the [CTM] are not used.

The standard PostScript® itransform operator specifies a transformationof a coordinate in device space (x′,y′) to user space (x,y) according tothe inverse of the [CTM] or a supplied matrix operand. The standardidtransform operator specifies a distance transformation from devicespace to user space according to the inverse of the [CTM] or a suppliedmatrix operand.

FIG. 22 illustrates the program steps implemented by the redefinedtransform operator. The other transform operators are redefined in thesame way. A decision-making block 534 first determines whether a matrixoperand was supplied to the transform operator. If a matrix operand wassupplied, a block 536 simply calls the standard transform operator (nowrenamed “systemdict_transform”) to perform the transformation accordingto the supplied matrix. (For the other transform operators, the block536 calls systemdict_dtransform, systemdict_itransform orsystemdict_idtransform).

Alternatively, if the block 534 determines that a matrix operand was notsupplied, a block 538 first saves a copy of the current [CTM] in thegraphics state on the Operands Stack.

As explained previously, the current [CTM] can be considered the resultof the concatenating the virtual [CTM] (saved in DefaultMatrix) with anoperations matrix. A block 540 thus calculates the operations matrix byconcatenating the current [CTM] with the inverse of the virtual [CTM].

Next, a block 542 sets a new [CTM] equal to the operations matrixconcatenated with the system default matrix. The new [CTM] is now equalto what the [CTM] would have been if the setvirtualdevice and impositionprocedures were not implemented.

A block 544 then calls the standard transform operator to perform thetransformation from user to device space according to the new [CTM].(Again, for the other transform operators, the block 544 calls thestandard dtransform, itransform, or idtransform operator).

Lastly, a block 546 resets the [CTM] equal to the current [CTM] saved onthe Operands Stack by the block 538.

The PostScript® transform operators may be redefined by the followingcode: /transform {  impositiondict begin  dup type /arraytype eq {  systemdict_transform % or systmdict_dtransform              % or             % systemdict_itransform          % orsystemdict_idtransform   } {   Matrix systemdict_currentmatrix   dup 4 1roll   DefaultMatrix   Matrix2 invertmatrix   Matrix3 concatmatrix  Matrix2 defaultmatrix   Matrix4 concatmatrix   systemdict_setmatrix  systemdict_transform  % or               % systemdict_dtransform         % or systemdict_itransform          % or systemdict_idtransform  3 −1 roll systemdict_setmatrix   } ifelse  end } bind defThe Redefined nulldevice Operator:

The standard PostScript® nulldevice operator installs a “null device” asthe current output device. The standard PostScript® nulldevice operatorproduces no physical output and has no associated raster memory.However, any graphics or font operations executed will be saved in thecurrent graphics state. The PostScript® nulldevice operator also setsthe [CTM] to an identity matrix ([1 0 0 1 0 0]) and establishes theclipping path as a single point at the origin.

The standard PostScript® nulldevice operator, however, is not suitablefor use with this invention because is not a page device operator and,therefore, has no EndPage and BeginPage procedures associated with it.Thus, the nulldevice operator is redefined to set the [CTM] to theidentity matrix and establish a one point clipping path without alteringthe current page device.

The PostScript® nulldevice operator may be redefined by the followingcode: /nulldevice {   impositiondict /Identity get  systemdict_setmatrix   newpath   clip } bind defThe Redefined copypage Operator:

Under normal operation, the standard PostScript® copypage operatortransmits one copy of the current page to the demand printer withouterasing the current page or changing the graphics state. Like theshowpage operator, the operation of the copypage operator depends on theEndPage and BeginPage procedures, which are redefined by the presentinvention. In the present invention, the EndPage and BeginPageprocedures are redefined so that the copypage operator has no affect.The EndPage and BeginPage procedures could be redefined to check for thecopypage operator (by comparing the reason code to one). Alternatively,the operation of the copypage operator can simply be nulled by thefollowing code:

/copypage { } def

The EnableVirtualDevice Procedure:

The EnableVirtualDevice procedure, which is called by the ImposeJobprocedure at the end of the instruction set, sets up the showpageoperator to support virtual devices. FIG. 23 is a flowchart illustratingthe program steps implemented by the EnableVirtualDevice procedure. Ablock 550 first determines whether the RIP 82 implements level 1 orlevel 2 PostScript® by determining whether the PostScript® setpagedeviceoperator is defined in the systemdict dictionary. If the RIP 82implements the level 2 PostScript® language, a block 552 loads theredefined EndPage and BeginPage procedures into the current graphicsstate for the demand printer 84 by calling the setpagedevice operator.As described in detail below, the EndPage and BeginPage procedures areredefined to define the current output device as a virtual device forpages to be rendered or as a scaled-down virtual device for non-renderedpages.

The blocks 550 and 552 of the EnableVirtualDevice procedure may beimplemented by the following code: /EnableVirtualDevice {   /setpagedevice where {    % level 2       pop       2 dict begin      /EndPage impositiondict /EndPage get def       /BeginPageimpositiondict /BeginPage get       def       currentdict end      setpagedevice       }

Alternatively, if the block 550 determines that the RIP 82 implementslevel 1 PostScript®, a block 554 renames the standard level 1 showpageoperator and a block 556 redefines the showpage operator to emulate theoperation of the level 2 showpage operator as illustrated in FIG. 20.Next, a block 558 executes the BeginPage procedure for the first page(page “0”) in the merged PostScript® file 450. (This was doneautomatically in the level 2 implementation by the block 552 by callingthe setpagedevice operator).

The blocks 554-558 may be implemented by the following code: {impositiondict /systemdict_showpage % rename systemdict /showpage getput % showpage /showpage { % emulate    impositiondict begin % level 2   PageCount 0 EndPage    systemdict_showpage    } if   systemdict_initgraphics    /PageCount PageCount 1 add def   PageCount /BeginPage load end exec    } def 0 impositiondict/BeginPage get exec } ifelse

Next, a block 560 invokes a procedure (called, for example,“DisablePageDevice”) which was previously stored in the impositiondictdictionary. The DisablePageDevice procedure redefines the PostScript®setpagedevice operator and all other compatibility operators that callthe setpagedevice operator. Disabling these operators ensures that theraster memory 452 (which may contain the raster descriptions ofpreviously processed pages to be rendered on the flat 456) is not erasedby the setpagedevice operator. The DisablePageDevice procedure isdescribed in detail below in connection with FIG. 24.

After the block 560 invokes the DisablePageDevice procedure describedabove, a block 562 sets the boolean variable called“VirtualDeviceEnabled” to true to indicate that the procedure has beencompleted and the showpage operator is set up to support virtualdevices.

The blocks 560 and 562 of the EnableVirtualDevice procedure may beimplemented by the following code: impositiondict /DisablePageDevice getexec impositiondict /VirtualDeviceEnabled true put } bind defThe DisablePageDevice Procedure:

FIG. 24 is a flowchart illustrating the program steps implemented by theDisablePageDevice procedure, which is invoked by the block 560 of theEnableVirtualDevice procedure. Because setpagedevice is a level 2operator, a block 570 determines whether the RIP 82 implements the level1 or the level 2 PostScript® language by determining whether thesetpagedevice operator is defined in the systemdict dictionary. If theRIP 82 implements the level 2 PostScript® language, blocks 572-580redefine the setpagedevice operator to correct the page orientation ofthe output device, if necessary.

During normal level 2 operation, a dictionary operand containing inputmedia selection entries is provided to the PostScript® setpagedeviceoperator and the setpagedevice operator establishes the current outputdevice according to the information contained in the current graphicsstate and the dictionary operand. The dictionary operand may contain,for example, an entry for PageSize, which is an array of two numbersindicating the width and height of the current page. Thus, a call to thesetpagedevice operator may alter the page size, which is critical insetting up the virtual device.

The block 572 of the redefined setpagedevice operator first determineswhether an entry for PageSize was included in the dictionary operand tothe setpagedevice operator. If so, the block 574 then determines whetherthe PageSize specified in the entry is portrait or landscape orientationby comparing the page width to the page height supplied in the PageSizeentry. (As explained above, for purposes of the invention, if the pagewidth is less than the page height, the orientation is referred to asportrait and the variable Portrait is set to true. If the page width isgreater than the page height, the orientation is referred to aslandscape and the variable Portrait is set to false).

A block 576 then compares the page orientation of the PageSize entry(determined by block 574) to the page orientation of the virtual device(stored in the variable Portrait). If they are not the same, a block 578invokes a procedure called, for example, “SetPortrait,” which changesthe orientation of the virtual device from portrait to landscape, orvice versa. (The SetPortrait Procedure is described in detail below).Next, for consistency with the normal operation of the setpagedeviceoperator, a block 580 calls the redefined initgraphics and erasepageoperators. Alternatively, if the block 576 determines that the pageorientation of the PageSize entry is the same as the virtual device, orif the block 572 determines that PageSize was not included in thedictionary operand to the setpagedevice operator, the program skipsdirectly to the block 580, which completes the redefinition of thesetpagedevice operator.

The blocks 570-580 of the DisablePageDevice procedure may be implementedby the following code: /DisablePageDevice {    /setpagedevice where {      pop       userdict       /setpagedevice {          dup /PageSizeknown {             /PageSize get             impositiondict begin            aload pop             lt Portrait ne {               SetPortrait                } if             end            } {             pop             } ifelse            initgraphics             erasepage          } put       } if

After the block 580 calls the redefined initgraphics and erasepageoperators, or if the block 570 determines that the RIP 82 implementslevel 1 PostScript®, a block 582 redefines the compatibility operators,which are defined in either the statusdict dictionary or the userdictdictionary, which call the setpagedevice operator or perform similarlevel 1 operations.

For compatibility operators that change the page orientation, the block582 redefines the operator to set the orientation of the virtual deviceequal to the orientation of the page specified by the operator and toinitialize the virtual device. These operators may be redefined by autility routine called, for example, “SetPageSize,” which is similar tothe blocks 576-580 described above. The SetPageSize routine may beimplemented by the following code: /SetPageSize {    lt Portrait ne { %correct orientation of virtual       SetPortrait %  device, if necessary      } if    initgraphics % initialize virtual device    erasepage %  (emulate setpagedevice) } bind def

For compatibility operators that do not affect the page orientation, theblock 582 simply disables or nulls the operators. The block 582 of theDisablePageDevice procedure, which redefines or disables thecompatibility operators, may be implemented by the following code:statusdict begin % operators in statusdict /a3tray {impositiondict begin842 792 SetPageSize end} def /a4tray {impositiondict begin 595 842SetPageSize end} def /ledgertray {impositiondict begin 1224 792SetPageSize end} def /setpage {pop pop pop} def /setpagestackorder {pop}def /settumble {pop} def /11x17tray {impositiondict begin 792 1224SetPageSize end} def /b5tray {impositiondict begin 516 729 SetPageSizeend} def /legaltray {impositiondict begin 612 1008 SetPageSize end} def/setdefaulttimeouts {pop} def /setduplexmode {pop} def /setmargins {poppop} def /setpagemargin {pop} def /lettertray {impositiondict begin 612792 SetPageSize end} def /setmirrorprint {pop} def /setpageparams {poppop pop pop} def /setresolution {pop} def end % operators in userdict/a3 {impositiondict begin 842 1191 SetPageSize end} def /b5{impositiondict begin 516 729 SetPageSize end} def /letter{impositiondict begin 612 792 SetPageSize end} def /lettersmall{impositiondict begin 612 792 SetPageSize end} def /legal{impositiondict begin 612 1008 SetPageSize end} def ledger{impositiondict begin 1224 792 SetPageSize end} def /11x17{impositiondict begin 792 1224 SetPageSize end} def /a4 {impositiondictbegin 595 842 SetPageSize end} def /a4small {impositiondict begin 595842 SetPageSize end} def /note { } defThe SetPortrait Procedure:

The SetPortrait procedure, which is invoked by the block 578 of theDisablePageDevice procedure, changes the orientation of the virtualdevice from portrait to landscape or vice versa. FIG. 25 illustrates theprogram steps implemented by the SetPortrait procedure. A block 590first determines whether the variable Portrait is true (indicating thepage is portrait) or false (indicating the page is landscape).

If Portrait is true, the orientation of the device must be convertedfrom portrait to landscape. As illustrated in FIG. 26A, aportrait-orientated page 592 is represented in a cartesian coordinatesystem with an origin at point O_(P). The portrait-orientated page 592has a width PageX and a height PageY. The rendering area on the page 592is bordered by a clipping path 594, which may be defined by thecoordinates of its lower-left corner (llx, lly) and the coordinates ofits upper-right corner (urx, ury).

The portrait-oriented page 592 is converted to a landscape-oriented page596 by translating the origin Op of the page 592 in the positivex-direction and then rotating the coordinate system 90 degreescounterclockwise, resulting in the landscape-orientated coordinatesystem of the page 596 with an origin OL Although the device spacecoordinates of the clipping path 594 are unchanged, the clipping path594 must be redefined with respect to the new landscape coordinatesystem.

Referring again to FIG. 25, after the block 590 determines that theorientation of the device must be converted from portrait to landscape,a block 600 redefines the corner coordinate variables as follows:Portrait Coordinate Landscape Coordinate ClipllX ClipllY ClipllY PageX -ClipurX ClipurX ClipurY ClipurY PageX - ClipllY

Next, blocks 602 and 604 create matrices which will translate the originO_(P) by the page width (PageX) in the positive x-direction and thenrotate the portrait coordinate system 90 degrees counterclockwise aboutthe origin O_(P). A block 606 then concatenates the matrices with thecurrent virtual [CTM] to create the new virtual [CTM], which specifiesthe device in landscape orientation.

The blocks 590 and 600-606 of the SetPortrait procedure may beimplemented by the following code: /SetPortrait {    Portrait {      /tmp ClipllX def       /ClipllY PageX ClipurX sub def      /ClipurX ClipurY def       /ClipurY PageX tmp sub def       90Matrix rotate       PageX 0 Matrix2 translate       DefaultMatrix      Matrix3 concatmatrix       DefaultMatrix concatmatrix       pop      }

If the block 590 determines that the variable Portrait is false, theorientation of the device must be converted from landscape to portrait.Referring also to FIG. 26B, a landscape-oriented page 608 is specifiedin a Cartesian coordinate system with an origin O_(L). The rendered areaon the page 608 is bordered by a clipping path 610 defined by thecoordinates of its lower-left and upper-right corners. Thelandscape-oriented page 608 is converted to a portrait-oriented page 612by translating the origin O_(L) in the positive y-direction and thenrotating the coordinate system 90 degrees clockwise about the originO_(L). This generates a portrait-oriented coordinate system with anorigin O_(P).

Similar to the above-described portrait to landscape procedure, a block614 first redefines the corner coordinates of the clipping path asfollows: Landscape Coordinate Portrait Coordinate ClipllY ClipllXClipllX PageY - ClipurY ClipurY ClipurX ClipurX PageY - ClipllY

Next, blocks 616 and 618 create matrices to translate the origin O_(L)in the positive y-direction and then rotate the origin O_(L) 90 degreesclockwise. A block 620 then concatenates the matrices with the currentvirtual [CTM] to generate the new virtual [CTM], which specifies thedevice in a portrait coordinate system.

The blocks 614-620 of the SetPortrait procedure, which convert fromlandscape to portrait orientation, may be implemented by the followingcode: /tmp ClipllY def /ClipllY ClipllX def /ClipllX PageY ClipurY subdef /ClipurY ClipurX def /ClipurX PageY tmp sub def −90 Matrix rotate 0PageY Matrix2 translate DefaultMatrix Matrix3 concatmatrix DefaultMatrixconcatmatrix pop } ifelse

After the clipping path corners are redefined and the new virtual [CTM]is generated, a block 622 exchanges the values of PageX and PageY. Thus,for example, when converting from portrait to landscape, the portraitpage width becomes the landscape page height and the portrait pageheight becomes the landscape page width. Lastly, a block 624 changes thevalue of the variable Portrait. Thus, if Portrait was initially true(indicating portrait orientation), it is set to false to indicate thatthe device is now in landscape orientation. Conversely, if Portrait wasinitially false (indicating landscape orientation), it is set to true toindicate that the device is now in portrait orientation.

The blocks 622-624 may be implemented by the following code:    /tmpPageX def    /PageX PageY def    /PageY tmp def    /Portrait Portraitnot def } bind def

The SetPortrait procedure described above comprises an optional part ofthe present invention and is not necessary for use with PostScript®applications which do not alter the page orientation.

The setvirtualdevice Procedure:

The setvirtualdevice procedure establishes the current transformationmatrix ([CTM]), the clipping path, and the page size such that thecurrent output device is specified as a virtual device. The virtualdevice is defined to be the size of the next page to be rendered, withthe origin and page boundary at the position on the flat 456 where thepage is to be rendered.

The setvirtualdevice procedure requires the following three “operands,”which are provided in the instruction set list:

1) the imposition procedure, which includes the scaling, translation androtation factors—[scale_x scale_y translate_x translate_y rotate];

2) the user space coordinates of the lower-left and upper-right cornersof the rendering area of the page to be imposed, which will be used togenerate a clipping path around the border of the virtual page in theraster memory 22—[clip_ll_x clip_ll_y clip_ur_x clip_ur_y]; and

3) the page width and page length—[page_size_x page_size_y].

FIG. 27 illustrates the program steps implemented by thesetvirtualdevice procedure. A block 630 first determines whether thevariable VirtualDeviceEnabled is set to true, indicating that theEnableVirtualDevice procedure has been executed and the showpageoperator is set up to support virtual devices. If the block 630determines that VirtualDeviceEnabled is false, a block 633 invokes theEnableVirtualDevice procedure. (A block 6333, which is implemented onlyin connection with the optional imposition-on-the-fly-procedures, willbe described below.)

Next, a block 634 defines the variables PageX and PageY as the width andheight of the virtual device, respectively. Similarly, a block 636defines the variables ClipllX and ClipllY as the x and y coordinates ofthe lower-left corner of the virtual device and the variables ClipurXand ClipurY as the x and y coordinates of the upper-right corner of thevirtual device.

A block 638 then calls the standard PostScript® initmatrix operator(renamed “systemdict_initmatrix”), which sets the [CTM] to the systemdefault matrix for the current output device. A block 640 then executesthe scale, translate and rotate operators with the operands to thesetvirtualdevice procedure. These scale, translate and rotate operationsalter the system default matrix to specify the virtual [CTM] . A block642 saves the resultant virtual [CTM] in the variable DefaultMatrix. Thevirtual [CTM] specifies that the origin of the virtual device is at_theposition on the flat where the next page is to be rendered on the flat456.

A decision-making block 644 then compares the page width (PageX) to thepage height (PageY). If PageX is less than PageY, a block 646 sets thevariable Portrait to true (indicating portrait orientation).Alternatively, if PageX is greater than PageY, a block 648 sets thevariable Portrait to false (indicating landscape orientation).

Next, a block 650 calls the redefined initclip operator to set theclipping path around the border of the virtual page. (See FIG. 21).

The setvirtualdevice procedure may be implemented by the following code:/setvirtualdevice {    impositiondict begin    VirtualDeviceEnabled not{ EnableVirtualDevice } if    aload pop    /PageY exch def % set pagesize    /PageX exch def    aload pop pop    /ClipurY exch def % setclipping path corners    /ClipurX exch def    /ClipllY exch def   /ClipllX exch def    systemdict_initmatrix    aload pop    5 −2 rollscale % execute scale, translate    3 −2 roll translate %  and rotate   rotate    DefaultMatrix systemdict_currentmatrix pop % set % [CTM]   /Portrait PageX PageY lt def    initclip % set clipping path    end }bind defThe ImposeJob Procedure:

The ImposeJob procedure is invoked after references to the mergedPostScript® files 450 and the instruction set have been placed on theOperands stack. Further, the above-described procedures and variableshave been loaded into the impositiondict dictionary.

FIG. 28 is a flowchart illustrating the program steps implemented by theImposeJob procedure according to the imposition-on-the-fly procedures ofthe present invention. A block 652 invokes the EnableVirtualDeviceprocedure, described above in connection with FIG. 23, to set up theshowpage operator to support virtual devices.

A block 654 then retrieves the first file/list pair (containing the nameof the merged PostScript® file and the corresponding entry list with theuser procedures, page numbers and operands for the setvirtualdeviceprocedures for the current flat 456) from the instruction set. Thefile/list pair is stored in an array that was placed on the OperandsStack prior to calling the ImposeJob procedure.

For each file/list pair, a block 656 invokes the ImposeFile procedure,described below, which retrieves each entry from the entry list anddetermines which pages described in the merged PostScript® file 450should be rendered on the flat 456. Assuming more than one file/listpair is contained in the array, the blocks 654 and 656 are implementedin a loop which individually retrieves each file/list pair from thearray and invokes the ImposeFile procedure to process each file/listpair.

After every file/list pair from the instruction set has been processedby the ImposeFile procedure, a block 658 sets the boolean variableImageDone to true. ImageDone will be used to instruct the RIP 82 thatthe imposition job is complete and the flat 456 can be ejected. Thevalue of ImageDone at this point could be determined by a globalvariable. ImageDone could also be set to true in the user procedure inthe last entry of the last instruction set list.

Next, a block 660 determines whether the showpage operator was redefinedto emulate level 2. If so, a block 662 executes the standard level 1showpage operator (renamed “systemdict_showpage”) in order to transmitthe contents of the raster memory 452 to the demand printer 84 forphysical rendering of the flat 456. In the level 2 implementation, theflat 456 is automatically rendered by the showpage operator when theredefined EndPage procedure returns a “true.” (See FIG. 20). If theshowpage operator was not redefined, a block 664 ends the program.

The blocks 652-662 of the ImposeJob procedure may be implemented by thefollowing code: /ImposeJob    % Impose pages from each input file {   impositiondict /EnableVirtualDevice get exec    { % Call ImposeFilefor       aload pop pop % each file in instruction % set      impositiondict /ImposeFile get       exec    } forall   impositiondict /ImageDone true put    impositiondict/systemdict_showpage    known { % Did we redefine_showpage      impositiondict /systemdict_showpage       get exec %If yes,execute it.       } if } def(Blocks 653 and 657 of the ImposeJob procedure, which are implementedonly in connection with the optional imposition-on-the-fly of theinvention, will be described below.)The ImposeFile Procedure:

FIG. 29 illustrates the program steps implemented by the ImposeFileprocedure of the imposition-on-the-fly procedures of the invention. Whenthe ImposeFile procedure is invoked, the Imposejob procedure has placeda file/list pair from the instruction set on the Operands stack. Thefile/list pair contains a list of entries (the “PageList”), wherein eachentry specifies:

1) a first user procedure;

2) the number of the page to rendered on the flat 456;

3) the operands to the setvirtualdevice procedure (which generates thevirtual [CTM] for properly positioning the page on the flat 456); and

4) a second user procedure (specifying offsets).

A block 670 sets the variable PageOffset=CurrentPage+PageOffset+1.CurrentPage (representing the number of the next page in the currentmerged PostScript® file 450 that is to be rendered on the flat 456) isinitially 0 and PageOffset (representing the cumulative number of pagesfrom previous files processed) is initially −1. Therefore, on the firstpass of the ImposeFile procedure, Pageoffset is equal to 0 (indicatingthat no previous files have been processed). A block 672 then uses thepointer CurrentIndex to retrieve the first entry from the entry listreceived from the ImposeJob procedure. A block 673 then retrieves thepage number from the entry and sets CurrentPage equal to its value.Thus, CurrentPage now specifies the number of the first page in thecurrent merged PostScript® file that should be rendered on the flat.

Next, a decision-making block 674 determines whether the first page inthe current PostScript® file (page number 0) should be rendered on theflat by comparing CurrentPage to 0. If CurrentPage is equal to 0, thefirst page in the merged PostScript® file 450 should be imposed andrendered on the flat, and a block 675 executes the first user procedurecontained in the current entry retrieved by the block 672.Alternatively, if the block 674 determines that the first page is not onthe flat, a block 676 pops the first user procedure from the retrievedentry from the stack.

After the block 675 has executed the user procedure or after the block676 pops the user procedure, a block 678 executes the setvirtualdeviceprocedure, which was described in detail above in connection with FIG.25. The setvirtualdevice procedure sets the virtual [CTM] and theclipping path according to the operands included in the retrieved entry.

The blocks 670-678 of the ImposeFile procedure may be implemented by thefollowing code: /ImposeFile {    impositiondict begin    /PageOffsetCurrentPage PageOffset add 1 add def    /PageList exch def   /CurrentIndex 0 def    PageList CurrentIndex get    % get entry   aload pop pop    5 −2 roll dup    /CurrentPage exch def % get pagenumber for 1st % page    0 eq { % if 1st page is on flat       exec %execute user procedure       } {       pop % if 1st page is not on %flat       } ifelse % pop user procedure    setvirtualdevice  % callsetvirtualdevice

Next, a decision-making block 680 determines whether the first page inthe current PostScript® file (page number 0) should be rendered on theflat by comparing CurrentPage to 0. If CurrentPage is not equal to zero(i.e. the first page should not be rendered on the flat), a block 682invokes a procedure called, for example, “MakeNull.” The MakeNullprocedure, which is described in detail below in connection with FIG.30, creates a scaled-down version of the virtual device for the nextpage to be rendered on the flat. The MakeNull procedure will be used toquickly interpret pages included in the merged PostScript® file 450 thatwill not be rendered on the current flat 456. The block 682 also callsthe redefined initclip operator (see FIG. 21).

After the block 682 executes the MakeNull procedure, or, alternatively,if the block 680 determines that CurrentPage is equal to zero (i.e. thefirst page should be rendered on the flat), a block 684 sets thevariable LastPage equal to the page number of the last page in thePostScript® file to be rendered on the flat. The last page is determinedby defining LastIndex as the number of entries in the instruction setminus one. The entries are indexed starting with zero (i.e., 0, 1, 2,3,) such that the last of four entries will be entry number 3).LastIndex is then used to retrieve the page number from the last entryin the entry list, which is stored in the variable LastPage. The block684 thus determines the number of page descriptions in the currentmerged PostScript® file 450 that need to be interpreted in order toproperly render all of the selected pages on the flat 456.

The blocks 680-684 of the ImposeFile procedure may be implemented by thefollowing code: /CurrentPage 0 ne { % if page is not on flat      MakeNull   % execute MakeNull % procedure    initclip    } if/LastIndex PageList length 1 sub def /LastPage PageList LastIndex get 1get def

A block 686 then opens the current merged PostScript® file 450, ifnecessary, and defines a file object (i.e. “TheFile”) to access thecurrent merged PostScript® file 450. The block 686 then interprets thecurrent merged PostScript® file 450, which contains various pagedescriptions, including the selected pages to be rendered on the currentflat 456. Each page description includes the showpage operator, whichwill invoke the redefined EndPage and BeginPage procedures of thepresent invention.

Preferably, the block 686 executes the merged PostScript® file 450 instopped mode, which dictates that the execution will stop once the lastpage that needs to be processed for the flat 456 is executed (determinedby the value of LastPage). Once execution is complete, a block 688flushes and closes the current PostScript® file and a block 690 returnsto the block 654 of the ImposeJob procedure (FIG. 26) to retrieve thenext file/list pair from the instruction set.

The blocks 686-690 of the ImposeFile procedure may be implemented by thefollowing code:    dup type 1 string type eq { (r) file } if    dup/TheFile exch def    cvx    end    stopped { count 0 eq dup not       {pop dup (done with current file) ne } if       { stop } { pop } ifelse   impositiondict /TheFile get dup flushfile    closefile } bind defThe MakeNull Procedure:

The MakeNull Procedure is invoked by the block 682 of the ImposeFileprocedure before processing pages that will not be rendered on thecurrent flat 456. The MakeNull Procedure creates a low resolution(scaled-down) replica of the virtual device for the next page to berendered on the flat. This low resolution virtual device allows for fastprocessing of the non-rendered pages. The non-rendered pages areprocessed using a low resolution replica of the virtual device for thenext page to be rendered on the flat to ensure that any marks generatedby the processing do not overwrite a portion of the flat 456 that isalready imaged.

The MakeNull procedure creates a low resolution replica of the virtualdevice by scaling the components of the virtual [CTM]. Further, theMakeNull procedure positions the scaled-down virtual device in themiddle of the original virtual device. This ensures that the scaled-downvirtual device will be completely contained within the clipping pathdefining the original virtual device.

As explained earlier, by definition, the virtual [CTM] contains thecomponents [a b c d t_(x) t_(y)] and specifies a transformation of thecoordinates (x, y) in user space to the coordinates (x′, y′) in devicespace as follows:x′=ax+cy+t _(x)y′=bx+dy+t _(y).

The PostScript® language includes a scale operator which creates atemporary matrix from supplied x and y scale factors and concatenatesthe temporary matrix with the current [CTM]. The scale operator thenreplaces the current [CTM] with the resultant matrix.

Invoking the PostScript® scale operator with x and y scale factors(s_(x) and s_(y)) as operands, the scaled [CTM]=[s_(x)a s_(x)b s_(y)cs_(y)d t_(x) t_(y)]. Thus, the new transformation from user to devicespace specified by the scaled [CTM] is given by:x′=s _(x) ax+s _(y) cy+t _(x)   (1)y′=s _(x) bx+s _(y) dy+t _(y).   (2)

The exact scale factors s_(x) and s_(y) may vary according to the typeof PostScript® RIP 82 used. However, a 1 to 1 ratio between user anddevice space coordinates leads to significantly faster processing ofpages over normal processing on a high resolution device. Also, thePostScript® nulldevice operator installs a [CTM] with a 1 to 1 ratio ofuser to device coordinates. Therefore, although the scale factors couldbe tuned for optimal performance on a given PostScript® RIP 82, it isassumed that a 1 to 1 ratio between user and device space coordinateswill run with reasonable efficiency on any PostScript® RIP 82. Thus, thescale factors s_(x) and s_(y) used by the MakeNull procedure arepreferably calculated to achieve a 1 to 1 ratio between user and devicespace as follows.

To achieve a 1 to 1 ratio between user and device space coordinates withonly the scale factors, the unit vector in user space from coordinatepoints (0,0) to (1,0) and from (0,0) to (0,1) must have unit length indevice space. Therefore,(x′(1,0), y′(1,0))−(x′(0,0), y′(0,0))=1   (3)and|(x′(0,1), y′(0,1))−(x′(0,0), y′(0,0))|=1.   (4)From equations (1) and (3),|(s _(x) a+t _(x) , s _(x) b+t _(y))−(tx, t _(y))=1|(s_(x)a, s_(x)b)|=1((s _(x) a)²+(s _(x) b)²)^(1/2)=1Thus, s_(x)=1/(a²+b²)^(1/2).Similarly, s_(y)=1/(c²+d²)^(1/2).

FIG. 30 illustrates the program steps implemented by the MakeNullprocedure. A block 698 first determines and saves the device spacecoordinates of the midpoint of the virtual clipping path. The midpoint(mpx, mpy) is determined by first retrieving the corner coordinates ofthe virtual clipping path, which are stored in the variables ClipllX,ClipurX, ClipllY, and ClipurY. The x-axis midpoint (mpx) is calculatedby adding the lower left and upper right x-axis corner coordinates(ClipllX and ClipurX) and dividing by two. Similarly, the y-axismidpoint (mpy) is calculated by adding the y-axis corner coordinates(ClipllY and ClipurY) and dividing by two. After the midpoint iscalculated, the standard PostScript® transform operator (renamed“systemdict_transform”) is executed to convert the user spacecoordinates to device space coordinates.

Next, a block 700 gets the virtual [CTM] which is stored in the variableDefaultMatrix. A block 702 then calculates the scale factors, s_(x) ands_(y), as specified above and a block 704 applies the scale factors tothe virtual [CTM]. A block 706 then saves the scaled virtual [CTM] asthe new virtual [CTM] in the variable DefaultMatrix.

A block 708 then sets the midpoint of the scaled clipping path(specified by the new virtual [CTM]) to correspond with the coordinatesof the midpoint of the original clipping path (saved by the block 698).The block 708 determines the difference between the saved midpointcoordinates and the new midpoint coordinates and then translates the newcoordinates by that difference.

The MakeNull procedure may be implemented by the following code:/MakeNull {    impositiondict begin    ClipllX ClipurX add 2 div ClillYClipurY add 2 div       systemdict_transform    /mpy exch def %calculate    /mpx exch def % midpoint    DefaultMatrix    dup    dup dup   dup 0 get dup mul   % compute a²    exch 1 get dup mul   % compute b²   add 1 exch div sqrt dup 1.0 gt   % compute s_(x)       { pop 1.0 } ifexch    dup 2 get dup mul   % compute c²    exch 3 get dup mul   %compute d²    add 1 exch div sqrt dup 1.0 gt   % compute s_(y)       {pop 1.0 } if    Matrix scale % scale matrix    exch Matrix2 concatmatrix% save as the new    systemdict_setmatrix % virtual default % matrix   ClipllX ClipurX add 2 div ClipllY ClipurY add 2 div      systemdict_transform    /mpy exch mpy sub neg def % translate   /mpx exch mpx sub neg def % midpoint    mpx mpysystemdict_idtransform translate    systemdict_currentmatrix pop end }bind defThe Redefined EndPage Procedure:

The page descriptions contained in the merged PostScript® file 450 allinclude the showpage operator, which will invoke the redefined EndPageand BeginPage procedures.

The redefined EndPage procedure updates the CurrentPage variable, whichrepresents the number of the next page in the merged PostScript® file450 that should be imposed and rendered on the flat. The redefinedEndPage procedure also calls the setvirtualdevice and MakeNullprocedures for the pages to be interpreted.

FIG. 31 is a flowchart illustrating the program steps implemented by theredefined EndPage procedure. A block 710 determines whether the EndPageprocedure was called by the showpage operator by determining whether thereason code is 0. A block 712 compares CurrentPage plus PageOffset toPageCount to determine whether the current page in the PostScript® fileshould be imposed and rendered on the flat 456.

Assuming both of the blocks 710 and 7122 are true, a block 713 set upsthe default environment by calling the standard initgraphics operator(now renamed “systemdict_initgraphics”). The block 713 then retrievesand executes the second user procedure (containing, for example, theoffset instructions) from the current entry. If the second userprocedure contains offset instructions, the PostScript® file will berepositioned to the start of the next page to be included in the book,thereby skipping processing of any irrelevant pages. If the second userprocedure contains other instructions (such as barcodes, watermarks,etc.), they will also be executed.

Next, a block 714 increments the pointer CurrentIndex, which will beused to retrieve the next entry from the entry list (PageList). Thedecision-making block 716 then determines whether there is another entryin the instruction set by comparing CurrentIndex to LastIndex.

If CurrentIndex is less than or equal to LastIndex, a block 718 resetsthe graphics state to its system default value by calling the standardPostScript® initgraphics operator (now renamed“systemdict_initgraphics”). A block 720 then uses CurrentIndex toretrieve the next entry in the entry list to place the operands for thesetvirtualdevice procedure on the Operands stack and a block 722 invokesthe setvirtualdevice procedure.

A block 724 then sets CurrentPage equal to the number of the page fromthe retrieved entry. CurrentPage is now updated to contain the number ofthe next page from the merged PostScript® file 450 that should beimposed and rendered on the flat 456.

Next, a block 726 invokes the MakeNull procedure to set up the lowresolution virtual device for processing of non-rendered pages. TheMakeNull procedure is called because it is assumed that the next page inthe merged PostScript® file 450 will not be rendered on the flat 456.(If the next page should be rendered on the flat, the redefinedBeginPage procedure, described in detail below, will establish thevirtual device for that page). A block 728 then removes the userprocedure (which is contained in the retrieved entry) from the OperandsStack.

If any of the blocks 710, 712 or 716 are false, or after the block 728pops the user procedure, a block 730 places the value of the variableImageDone on the stack. If ImageDone has the value of true, indicatingthat the flat is completed, the calling of the EndPage procedure (i.e.,by the showpage operator or for new device activation) willautomatically transfer the contents of the raster memory 452 to thedemand printer 84 to physically render the selected pages on the flat456. (See FIG. 19).

A block 732 then resets ImageDone to false to specify that the flat isnot completed and the contents of the raster memory 452 will not yet betransferred to the demand printer 84 for physical rendering.

The redefined EndPage procedure may be implemented by the followingcode: /EndPage {   impositiondict begin   0 eq   exch   CurrentPagePageOffset add eq   and {     systemdict_initgraphics     PageListCurrentIndex get     5 get exec     /CurrentIndex CurrentIndex 1 add def    CurrentIndex LastIndex le {       systemdict_initgraphics      PageList CurrentIndex get       aload pop       setvirtualdevice      /CurrentPage exch def       MakeNull       pop       } if     } if  ImageDone   /ImageDone false def   end } bind defThe Redefined BeginPage Procedure:

FIG. 32 is a flowchart illustrating the program steps implemented by theredefined BeginPage procedure. A block 740 first calls the redefinedinitmatrix operator to set the virtual [CTM].

Referring also to FIG. 20, the BeginPage procedure receives PageCount asan operand from the showpage operator. A decision-making block 742compares CurrentPage (which was updated by the block 724 of theredefined EndPage procedure of FIG. 31) to PageCount. CurrentPagecontains the number of the next page in the PostScript® file to berendered on the flat 456. Thus, if CurrentPage and PageCount are equal,the current page in the merged PostScript® file 450 should be imposedand rendered on the flat 456 and a block 744 retrieves the next entry(containing the user procedures, page number and setvirtualdeviceoperands) from the entry list.

A block 745 then executes the user procedure from the retrieved entryand a block 746 invokes the setvirtualdevice procedure to set up thevirtual [CTM] and clipping path for the virtual device (see FIG. 27). Ablock 748 then pops the page number from the retrieved entry.

Next, a block 750 “blanks out” the virtual page by coloring the areainside of the clipping path white. This is necessary to erase any straymarks that may have been placed on the page when the non-rendered pageswere processed using the MakeNull procedure.

Alternatively, if the block 742 determines that the next page in themerged PostScript® file 450 should not be rendered on the flat (i.e.CurrentPage is not equal to PageCount), a decision-making block 752compares PageCount to LastPage plus Pageoffset. If PageCount is greaterthan LastPage plus Pageoffset, subsequent pages in the PostScript® filedo not need to be interpreted because they are beyond the last page thatshould be rendered on the flat 456. Thus, a block 754 stops theexecution of the merged PostScript® file 450. As explained earlier, theImposeFile procedure executes the merged PostScript® file 450 in stoppedcontext. In order to distinguish between the expected stop in the block754 and an unexpected stop caused, for example, by a PostScript® error,the string “done with current file” is generated by the block 754 of theredefined BeginPage procedure. Referring also to FIG. 27, the block 386of the ImposeFile procedure checks for the “done with current file”string to determine when to proceed to the block 688 to flush and closethe merged PostScript® file 450.

Alternatively, if the block 752 determines that PageCount is less thanor equal to LastPage plus Pageoffset (i.e. the current page is beforethe last page to be rendered on the flat), a block 756 calls theredefined initclip operator to reset the virtual clipping path. (SeeFIG. 20).

The redefined BeginPage procedure may be implemented by the followingcode: /BeginPage {   initmatrix   impositiondict begin   dup  CurrentPage PageOffset add eq { % page on flat     pop % pop PageCount    PageList CurrentIndex get % get entry     aload pop     5 −1 roll    exec % execute user procedure     setvirtualdevice     pop % pop thepage number     clippath 1 setgray fill % blank out virtual % page     0setgray newpath     } bind { % page not on % flat     LastPagePageOffset add gt {       end (done with current file) stop } if    initclip     } ifelse   end } bind defThe ImageDone Variable:

As explained earlier, the variable ImageDone is a boolean variable usedto indicate when all the pages for the current flat 456 have beeninterpreted and painted into the raster memory 452 such that the flat456 can be physically rendered by the demand printer 84. ImageDone isinitially and normally set to false, indicating that the current flat456 has not yet been completed. However, referring to FIG. 26, after allthe file/list pairs from the instruction set have been processed by theImposeJob procedure, the block 658 sets ImageDone to true to indicatethat the flat is completed. Also, the user procedure contained in thelast entry in a file/list pair in the instruction set could include aninstruction to set ImageDone to true to specify that the current flat iscompleted.

The ImageDone variable is used by the redefined EndPage procedure.Referring to FIGS. 20 and 31, the block 730 of the redefined EndPageprocedure returns the value of ImageDone to the block 502 of theshowpage operator. If ImageDone is true, the block 504 transmits thecontents of the raster memory to the demand printer to render thecurrent flat.

The ImageDone variable may be utilized to allow for multiple flats to berendered by a single file/list pair in. the instruction set (seeAppendix I sample instruction set).

The Showdevice Procedure:

The imposition-on-the-fly procedures may include an additionalprocedure, called, for example, “showdevice,” which uses the ImageDonevariable to allow a user to render the flat at any time. The showdeviceprocedure sets ImageDone to true and then calls the showpage operator,which will invoke the redefined EndPage procedure and render the currentflat, as described above.

The showdevice procedure may be implemented by the following code:/showdevice {   impositiondict /ImageDone true put   showpage } def

The showdevice procedure will normally be used when a user implementsthe setvirtualdevice (and related) procedures in a non-impositionapplication in which the ImposeJob and ImposeFile procedures areeliminated. For example, the showdevice procedure could be implementedto render any selected page(s) contained in the merged PostScript® file450.

Optional Imposition-on-the-Fly Procedures:

Optionally, additional procedures may be included in theimposition-on-the-fly procedures which will allow the proper impositionof page descriptions using the PostScript® save and restore operators.

The PostScript® save operator takes a “snapshot” of the state of virtualmemory, which stores all values of composite objects, such as stringsand arrays. Many of the variables used by the imposition-on-the-flyprocedures of the present invention are stored in virtual memory. Thesave operator also saves the current graphics state by pushing a copy ofthe current graphics state onto the Graphics State Stack. ThePostScript® restore operator restores the virtual memory and the currentgraphics state to the state at the time the corresponding save operatorwas executed.

The PostScript® gsave operator pushes a copy of the current graphicsstate onto the Graphics State Stack and the PostScript® grestoreoperator pops the saved graphics state from the Graphics State Stack andrestores it as the current graphics state. The PostScript® grestorealloperator restores either the bottom-most graphics state stored on theGraphics State Stack or the first graphics state that was stored by thesave operator (as opposed to the gsave operator). The elements of thecurrent graphics state affected by these operators includes the current[CTM], clipping path and, current path. However, they do not affect thecontents of the raster memory 452.

The PostScript® save and restore operators may adversely affect theimposition-on-the-fly procedures of the present invention, as well as onother imposition methods. The problem arises if a page description inthe merged PostScript® file 450 invokes a save operator, which will savethe [CTM] that specifies the desired position for that page on thedevice. If a subsequent page description invokes a restore operator, the[CTM] for the prior page will replace the [CTM] for the subsequent page.Thus, the subsequent page will be incorrectly positioned on the flat456.

To overcome this problem, two new procedures (Vsave and Vrestore) areused in connection with the above-described procedures. The Vsave andVrestore procedures will be used to redefine the PostScript® save andrestore operators such that they do not interfere with the otherimposition-on-the-fly procedures of the present invention.

The Vsave Procedure:

Generally, the Vsave procedure appends the page size components (PageXand PageY) and the virtual [CTM] components (which define the virtualdevice) to the current path, which will be saved by the PostScript® saveoperator. Later, the Vrestore procedure will retrieve these components,remove them from the current path, and use them to generate the correctclipping path, page orientation and [CTM] for the restored page.

FIG. 33 is a flowchart illustrating the program steps implemented by theoptional Vsave procedure. A block 800 saves a copy of the current [CTM]and then a block 801 sets the [CTM] equal to an identity matrix ([1 0 01 0 0]).

The identity matrix is used because all points used to describe thecurrent path are specified in user space coordinates. However, at thetime a PostScript® program enters a point into the current path, eachcoordinate is transformed into device space according to the [CTM].Thus, the identity matrix will be used when adding the components to thecurrent path to avoid any round off errors that may occur in thisconversion from user space to device space.

A decision-making block 802 then determines whether a currentpoint isdefined. If a currentpoint is defined, a block 804 sets the variable p1equal to the current path. This may be accomplished by invoking thepreviously defined MakePath procedure, which creates a description ofthe current path in the current coordinate system. (The MakePathprocedure was described above in connection with the block 524 of theredefined initclip operator of FIG. 20).

A block 806 then defines a variable called, for example, “firstop” to bethe PostScript® lineto operator. By definition, the PostScript® linetooperator adds a straight line segment to the current path by connectingthe previous current point to the new one.

Alternatively, if the block 802 determines that no currentpoint exists,a block 808 sets p1 equal to an empty path. A block 810 then definesfirstop to be the PostScript® moveto operator, which establishes a newcurrentpoint.

After firstop is defined by either the block 806 or the block 810, ablock 812 creates an “unlimited” bounding box for the current path. Abounding box, which is normally established by the PostScript® setbboxoperator, defines the area in which the current path coordinates mustfall. The operands to the setbbox operator are the user spacecoordinates of the lower-left and upper-right corners of the boundingbox. Since the page size and [CTM] components will be added to thecurrent path during the Vsave procedure, the bounding box must be setlarge enough to encompass the “points” defined by those components.Thus, a previously defined procedure called, for example, “SetBigBBox,”may be invoked to set the bounding box to be the largest possible. TheSetBigBBox procedure may be implemented by the following code:/SetBigBBox /setbbox where {   pop {     −2147483648 −21474836482147483648 2147483648     setbbox     } bind def   } {   {   } def }ifelse

After the large bounding box is set, a block 814 invokes the firstopoperator (defined by the block 806 or the block 810) to append the pagesize components (PageX and PageY) to the current path. Next, a block 818appends the virtual [CTM] components (stored in the variableDefaultMatrix) to the current path. A block 820 then replaces theidentity [CTM) with the [CTM] that was saved by the block 800.

The Vsave procedure may be implemented by the following code: /Vsave {  Matrix systemdict_currentmatrix   dup   Identity systemdict_setmatrix% [CTM] = % identity   { currentpoint} stopped { % no current % point  /p1 { } def % define empty % path     /firstop { moveto } def     } {% current point     pop pop % create real % path     /p1 MakePath def    /firstop { lineto } def     } ifelse   SetBigBBox   PageX PageYfirstop % append page % size   DefaultMatrix   aload pop   lineto %append [CTM]   lineto   lineto   systemdict_setmatrix } bind defThe Vrestore Procedure:

The Vrestore procedure retrieves the page size and virtual [CTM]components (which defined the virtual device) appended to the currentpath by the Vsave procedure and uses them to generate the correctclipping path, page orientation and virtual [CTM] for the restored page.

FIG. 34 is a flowchart illustrating the program steps implemented by theVrestore procedure. A block 830 saves the current [CTM] and a block 832then sets the [CTM] to an identity matrix. As in the Vsave procedure,the use of the identity [CTM] will avoid any round off errors whentransforming coordinates from user space to device space in the currentpath.

A block 834 then retrieves the elements of the current path by callingthe PostScript® pathforall operator, which pushes the user spacecoordinates of each path element onto the Operands stack. The retrievedelements will include the page size and virtual [CTM] components thatwere appended to the path by the Vsave procedure. A block 836 thenperforms various stack manipulation operations to place the page sizeand virtual [CTM] components on top of the stack. The block 836 thenstores the components in variables called, for example,“ResDefaultMatrix,” “ResPageX” and “ResPageY,” which represent the pagesize and virtual [CTM] at the time that the PostScript® save operatorwas called.

Next, a decision-making block 838 compares the ResDefaultMatrix (at timeof save) to the current virtual [CTM] (at time of restore), which issaved in the variable DefaultMatrix. The equivalency of the matrices maybe easily determined by using a previously defined utility routine,called, for example, “EqualMatrix,” which performs acomponent-by-component comparison of the two matrices, allowing for aslight floating point round-off error. If the two matrices areequivalent, the EqualMatrix routine returns a true on the stack; if theyare not equivalent, the EqualMatrix routine returns a false. TheEqualMatrix routine may be implemented by the following code:/EqualMatrix {   true   impositiondict begin   /Count 0 def   6 { 1index Count get 3 index Count get     eq     sub abs .0001 lt and    /Count Count 1 add def } repeat   3 1 roll pop pop   end } bind def

If the block 838 determines that the restored [CTM] and current [CTM]are not equivalent, it is assumed that the save operator was calledduring interpretation of one page and the restore operator was calledduring interpretation of another page. A block 840 then sets the [CTM]back to the value saved by the block 830. Next, a block 842 calls p1,which contains the current path at the time the save operator wascalled. The block 842 then removes the page size and [CTM] componentsthat were added to the current path and sets p1 equal to the remainingpath elements.

The blocks 830-842 of the Vrestore procedure may be implemented by thefollowing code: /Vrestore {   Matrix systemdict_currentmatrix   Identitysystemdict_setmatrix   mark   { } { } { } { } pathforall   6 2 roll   42 roll   mark 7 1 roll   ] /ResDefaultMatrix exch def   /ResPageY exchdef   /ResPageX exch def   cleartomark   DefaultMatrix ResDefaultMatrixEqualMatrix not   {     systemdict_setmatrix     /p1 mark     MakePathaload pop     pop pop pop     pop pop pop     pop pop pop     pop poppop     ] cvx def

Next, a decision-making block 844 determines the orientation of therestored page by comparing ResPageX to ResPageY. If ResPageX is greaterthan ResPageY, a variable called ResPortrait is set to false to indicatea landscape orientation. Alternatively, if ResPageX is less thanResPageY, the variable ResPortrait is set to true to indicate a portraitorientation. The block 844 then compares ResPortrait (the restored pageorientation) to Portrait (the saved page orientation). If the pageorientation has changed (ResPortrait and Portrait are not equal), ablock 846 calls the SetPortrait procedure to change the orientation ofthe device. (See FIGS. 25 and 26A&B).

The blocks 844 and 846 of the Vrestore procedure may be implemented bythe following code: ResPageX ResPageY gt {   /ResPortrait false def   }{   /ResPortrait true def   } ifelse ResPortrait Portrait ne {  SetPortrait   } if

If the block 844 determines that the orientation is the same, or afterthe block 846 corrects the orientation, a block 848 saves the proceduresfor generating the current clipping path in a variable called, forexample, “c1,” by calling the MakePath procedure.

A block 850 then calculates the new [CTM] by determining theaccumulation of operations applied on the restored virtual [CTM] andapplying those operations on the current virtual [CTM] . The block 850calculates the new [CTM] by first getting the current [CTM), which maybe considered the result of the restored virtual [CTM] (i.e., thevirtual [CTM] restored from the save operator) concatenated with anoperations matrix. The block 850 then calculates the operations matrixby concatenating the current [CTM] with the inverse of the restoredvirtual [CTM]. The operations matrix is then concatenated with thecurrent virtual [CTM] to generate the new [CTM]. Thus, the block 850assumes that:[current CTM]=[operations][restored virtual CTM].Further, the block 850 performs the following operations:[operations]=[current CTM][restored virtual CTM] ⁻¹;and[new CTM]=[operations][current virtual CTM].

The blocks 848 and 850 of the Vrestore procedure may be implemented bythe following code: clippath     % generate clip path procedures /clMakePath def Matrix systemdict_currentmatrix % calculate newResDefaultMatrix % [CTM] Matrix2 invertmatrix Matrix3 concatmatrixDefaultMatrix Matrix4 concatmatrix   systemdict_setmatrix

A block 852 then regenerates the clipping path (saved in c1) and a block854 regenerates the current path (saved in p1) in the new coordinatesystem specified by the new [CTM]. The blocks 852 and 854 may beimplemented by the following code: systemdict_initclip newpath c1 clipnewpath p1 }

Alternatively, if the block 838 determines that the restored virtual[CTM] is equivalent to the current virtual [CTM] (i.e., the save andrestore operators were called on the same page), a block 856 simplyremoves the page size and virtual [CTM] components from the currentpath. A block 858 then restores the current path and a block 860 setsthe [CTM] back to the value saved by the block 830.

The blocks 856-860 may be implemented by the following code:   {   /p1mark   MakePath aload pop   pop pop pop   pop pop pop   pop pop pop  pop pop pop   ] cvx def   newpath   p1   systemdict_setmatrix   }ifelse } bind defThe Redefined PostScript® Save Operators:

The PostScript® save operators (which include save and gsave) areredefined to invoke the Vsave procedure. Before the operators areredefined, however, they are renamed (“systemdict_operator,” forexample) because their normal operation is defined in the systemdictdictionary. The save operators may be renamed by the following code:

/systemdict_save systemdict /save get def

/systemdict_gsave systemdict /gsave get def

The PostScript® save and gsave operators are then redefined. FIG. 35 isa flowchart illustrating the program steps implemented to redefine toPostScript® save operators. A block 872 first invokes the Vsaveprocedure, which was described above in connection with FIG. 33. TheVsave procedure saves the current path in pi and then appends the pagesize and virtual [CTM] components to the current path.

A block 874 then invokes the standard PostScript® save (or gsave)operator (now renamed “systemdict_save” Cr “systemdict_gsave”). The saveoperator performs its standard function of saving the current state ofvirtual memory and the current graphics state, including the currentpath (which now includes the page size and virtual [CTM] components).The gsave operator performs its standard function of saving the currentgraphics state.

Next, a block 876 sets the [CTM] to an identity matrix. As before, thiswill eliminate any round off errors in the current path. A block 878then restores the current path to the path stored in p1 (the pathwithout the added page size and virtual [CTM] components) and a block880 restores the [CTM] back to the virtual [CTM].

The blocks 870-880 for redefining the PostScript® save operator may beimplemented by the following code: /save {   impositiondict begin  Vsave   systemdict_save   Identity systemdict_setmatrix   newpath   p1  exch systemdict_setmatrix   end } bind def

Similarly, the PostScript® gsave operator may be redefined byimplementing the following code: /gsave {   impositiondict begin   Vsave  systemdict_gsave   Identity systemdict_setmatrix   newpath   p1  systemdict_setmatrix   end } bind defThe Redefined PostScript® Restore Operators:

The PostScript® restore operator must also be renamed and redefined toinvoke the Vrestore procedure. Like the save operators, the restoreoperator is renamed, for example, “systemdict_restore,” by the followingcode:

/systemdict_restore systemdict /restore get def

Because the PostScript® save and restore operators affect the contentsof virtual memory and the graphics state, the values of many variablesused during the imposition and setvirtualdevice procedures may beinadvertently altered by the use of these operators.

However, simple values stored on the Operands Stack are not affected.Therefore, the PostScript® restore operator is redefined to protect thevalues of the variables stored in virtual memory by saving them on theOperands Stack before calling the standard PostScript® restore operator.

FIG. 36 is a flowchart illustrating the program steps implemented by theredefined restore operator. A block 892 places the values of all theimposition variables stored in virtual memory on the Operands stack sotheir values are not overwritten by the restore operator. Then, a block894 calls the standard restore operator (now renamed“systemdict_restore”). A block 896 then puts the values of the variableson the Operands stack back to their pre-restore values. Lastly, a block898 invokes the Vrestore procedure.

The blocks 892-898 of the redefined restore operator may be implementedby the following code: /restore {   impositiondict begin   ImageDone %put variables on stack   CurrentIndex   CurrentPage   PageCount  Portrait   PageX   PageY   ClipllX   ClipllY   ClipurX   ClipurY  mark DefaultMatrix % put [CTM] components on   aload pop %  stack   19−1 roll   systemdict_restore % call standard restore operator   ]  /DefaultMatrix exch def % replace variables with   /ClipurY exch def %pre-restore values   /ClipurX exch def   /ClipllY exch def   /ClipllXexch def   /PageY exch def   /PageX exch def   /Portrait exch def  /PageCount exch def   /CurrentPage exch def   /CurrentIndex exch def  /ImageDone exch def   Vrestore % invoke Vrestore procedure   end }bind defThe Redefined PostScript® grestore Operators:

The standard PostScript® grestore or grestoreall operators, are renamed,for example, “systemdict_operator.” This may be implemented by thefollowing code:

/systemdict_grestore systemdict /grestore get def

/systemdict_grestoreall systemdict /grestoreall get def

Because the PostScript® grestore and grestoreall operators affect onlythe graphics state, it is not necessary to protect the values of anyvariable stored in virtual memory. Thus, the grestore or grestorealloperators are more simply redefined.

FIG. 37 is a flowchart illustrating the program steps implemented by theredefined PostScript® grestore and grestoreall operators. A block 902invokes the renamed standard grestore or grestoreall operator and then ablock 904 invokes the Vrestore procedure, which will calculate thecorrect [CTM] and correct the page orientation and clipping path.

The blocks 902-904 for redefining the PostScripts grestore operator maybe implemented by the following code:   /grestore {     impositiondictbegin     systemdict_grestore     Vrestore     end   } bind def  Similarly, the grestoreall operator may be redefined by implementingby the following code:   /grestoreall {     impositiondict begin    systemdict_grestoreall     Vrestore     end   } bind defThe PostScript® Level 2 Gstate Operators:

Level 2 PostScript® implementations support the following threeadditional operators that affect the current graphics state (andtherefore the [CTM]) and that may interfere with the impositionprocedures of the present invention: gstate, currentgstate andsetgstate. The PostScript® gstate operator creates a new graphics stateobject (whose initial value is the current graphic state) and pushes iton the Operand stack. The PostScript® currentgstate operator replacesthe value of the gstate object with the current graphics state. ThePostScript® setgstate operator replaces the current graphics state withthe value of the gstate object.

Similarly to the gsave and grestore operators described above, thegstate operators are renamed and redefined to invoke the Vsave theVrestore procedures. The gstate operators may be renamed by thefollowing code:  /gstate where {    % is this level 2?   pop  /systemdict_gstate systemdict /gstate get def   /systemdict_setgstatesystemdict /setgstate get def   /systemdict_currentgstate systemdict    /currentgstate get def  } if

Similar to the redefined gsave operator described above in connectionwith FIG. 35, the gstate and currentgstate-operators are redefined tofirst invoke the Vsave procedure and then to call the renamed standardgstate or currentgstate operator. The redefined operators then restorethe current path without the page size and [CTM] components and resetthe virtual [CTM].

Also, like the redefined grestore operator described above in connectionwith FIG. 37, the setgstate operator is redefined to first call therenamed setgstate operator and then to invoke the Vrestore procedure.

The PostScript® level 2 gstate operators may be redefined by thefollowing code: /gstate where { % is this level 2?   pop   /gstate { %redefine gstate operator     impositiondict begin % (like gsaveoperator)     Vsave     systemdict_gstate     Identitysystemdict_setmatrix     newpath     p1     exch systemdict_setmatrix    end     } bind def   /currentgstate {  % redefine currengstateoperator     impositiondict begin % (like gsave % operator)     Vsave    systemdict_currentgstate     Identity systemdict_setmatrix    newpath     p1     exch systemdict_setmatrix     end     } bind def  /setgstate {  % redefine setgstate operator     impositiondict begin %(like grestore % operator)     systemdict_setgstate     Vrestore     end    } bind def   } if

These optional procedures are used when it is anticipated that the pagedescriptions in the merged PostScript® file 450 may include a saveoperator in one page description and a restore operator in a subsequentpage description. If the optional procedures are used, a slightmodification should be made to the setvirtualdevice procedure, describedabove in connection with FIG. 27. Referring to FIG. 27, an additionalblock 633 invokes the redefined save operator and then pops the saveobject from the Operands Stack after the block 6322 invokes theEnableVirtualDevice procedure. This is necessary because the grestoreand grestoreall operators can be called without a corresponding save orgsave operator. If grestore is called without a gsave operator, itrestores the graphics state from the top of the graphics state stack. Ifgrestoreall is called without a gsave or save operator, it restoreseither the graphics state from the bottom of the graphics state stack orthe graphics state saved by the last save operator. If the topmost saveobject was created prior to the redefinition of the save operator, thesaved current path will not include the additions of the page size and[CTM] components and, therefore, will not operate properly with theredefined grestore and grestorall operators. Thus, invoking theredefined save operator at the block 633 of the setvirtualdeviceProcedure ensures that the grestore and grestoreall operators willalways restore a saved graphics state compatible with the presentinvention.

The blocks 630-633 of the setvirtualdevice procedure for the thirdembodiment of the invention may be implemented by the following code:

VirtualDeviceEnabled not {EnableVirtualDevice save pop} if

Also, in some PostScript® applications, interpreting differentPostScript® files consecutively may interfere with the operation of theinvention. For example, two different PostScript® files may use the samename for variables with different definitions. If the second PostScript®file interpreted does not explicitly initialize the variable, thedefinition of the variable from the first PostScript® file will be used,interfering with proper interpretation of the second PostScript® file.To overcome this problem, the ImposeJob procedure (FIG. 28) may bealtered.

Referring to FIG. 28, blocks 653 and 657 are added to the ImposeJobprocedure to save the state of virtual memory (which includes manyvariable definitions) before retrieving a file/list pair from theinstruction set and restoring that saved state before retrieving thenext file/list pair. Specifically, the block 653 executes the redefinedsave operator and stores the saved state in a variable called, forexample, “SavedState.” The blocks 654 and 656 then retrieve a file/listpair from the instruction set and invoke the ImposeFile procedure toprocess the file/list pair, as described above. However, after theImposeFile procedure finishes processing each entry in the file/listpair, the block 657 retrieves the saved state stored in the variableSavedState and executes the redefined restore operator to restore thatstate. The block 657 thus initializes the virtual memory before theblock 654 retrieves the next file/list pair from the instruction set.

The blocks 650-662 of the ImposeJob procedure incorporating the blocks653 and 657 may be implemented by the following code: /ImposeJob %Impose pages from each input % file {  impositiondict/EnableVirtualDevice get exec  {   aload pop pop   impositiondict/SavedState    save put % save state   impositiondict /ImposeFile    get% call ImposeFile for each   exec % file in instruction set %cleardictstack   clear   impositiondict /SavedState get    restore %restore saved state  } forall  impositiondict /ImageDone true put impositiondict /systemdict_showpage  known { % Did we redefine showpage  impositiondict /systemdict_showpage   get exec % If yes, execute it.  } if } def

Further, as explained earlier, for compatibility with the optionalprocedures, the PostScript® erasepage operator is redefined by callingthe systemdict_gsave and grestore operators. All of the remainingimposition-on-the-fly procedures are compatible with the optionalprocedures.

Numerous modifications and alternative embodiments of the invention willbe apparent to those skilled in the art in view of the foregoingdescription. Accordingly, this description is to be construed asillustrative only and is for the purpose of teaching those skilled inthe art the best mode of carrying out the invention. The details may bevaried substantially without departing from the spirit of the invention,and the exclusive use of all modifications which are within the scope ofthe appended claims is reserved.

1-13. (canceled)
 14. An apparatus for controlling an electronic press,comprising: means for developing first and second sets of template datarepresenting associated first and second template pages, respectively,each set of template data having reusable data representing informationto be printed on more than one output page and position datarepresenting a position on a page at which variable information is to beprinted; and means responsive to the developing means and to a databasehaving a number of entries each of which represents variable printedinformation for causing the electronic press to print output pages withthe reusable data and selected variable printed information, wherein thecausing means comprises means for identifying the reusable data for eachset of template data prior to rasterization.
 15. The apparatus of claim14, wherein the causing means includes means for converting the sets oftemplate data and the database into commands for the electronic pressspecifying sequence and content of page production.
 16. The apparatus ofclaim 14, wherein the identifying means includes means for generating areusable data set representing the reusable data from the sets oftemplate data.
 17. The apparatus of claim 16, wherein the identifyingmeans further includes means for generating variable data setsrepresenting the variable information from the sets of template data.18. The apparatus of claim 14, wherein auxiliary production devices arecoupled to the causing means and wherein the database includes controlinformation for controlling at least one of the electronic press and theauxiliary production devices.
 19. The apparatus of claim 14, wherein thecausing means further includes means for controlling a furtherelectronic press such that a first portion of the output pages isprinted by the further electronic press and a second portion of theoutput pages is printed by the first-named electronic press.
 20. Theapparatus of claim 14, wherein the first set of template data and thesecond set of template data are different so that the first and secondtemplate pages are different.
 21. The apparatus of claim 20, wherein thereusable data of the first and second sets of template data aredifferent such that the reusable data of the first and second templatepages are different.
 22. The apparatus of claim 14, wherein the reusabledata of the first and second sets of template data are identical, and aposition of the reusable data in the first template page differs from aposition of the reusable data in the second template page.
 23. Theapparatus of claim 14, wherein the variable information of the first andsecond sets of template data are identical, and the position of thevariable information in the first template page differs from theposition of the variable information in the second template page.
 24. Anapparatus for controlling an electronic press, comprising: means fordeveloping template data representing a template page, the template datahaving reusable data representing information to be printed on more thanone output page and position data representing a position on a page atwhich variable information is to be printed; and means responsive to thedeveloping means and to a database having a number of entries each ofwhich represents variable printed information for causing the electronicpress to print output pages with the reusable data and selected variableprinted information, wherein the causing means comprises means foridentifying the reusable data for the template data prior torasterization.
 25. The apparatus of claim 24, wherein the causing meansincludes means for converting the template data and the database intocommands for the electronic press specifying sequence and content ofpage production.
 26. The apparatus of claim 24, wherein the identifyingmeans includes means for generating a reusable data set representing thereusable data from the template data.
 27. The apparatus of claim 24,wherein the identifying means further includes means for generating avariable data set representing the variable information from thetemplate data.
 28. The apparatus of claim 24, wherein auxiliaryproduction devices are coupled to the causing means and wherein thedatabase includes control information for controlling at least one ofthe electronic press and the auxiliary production devices.
 29. Theapparatus of claim 24, wherein the causing means further includes meansfor controlling a further electronic press such that a first portion ofthe output pages is printed by the further electronic press and a secondportion of the output pages is printed by the first-named electronicpress.